Soundbridge selective transcoding #1665
Comments
|
Sounds like it should be possible, I'll look into it. |
|
For testing this concept, I have made a branch with a very rudimentary implementation where the transcoding is switched to CBR MP3 at 256 kbit/s. Could you try if this works with a flac and the Soundbridge? This is the branch: https://github.com/owntone/owntone-server/tree/rspmp3 |
|
I get httpd: Transcoding error, file id 37484 in the log. Also, if it's not obvious, the Soundbridge does not play. |
|
Which version of ffmpeg is it? Also, can you confirm it doesn't play and you get the same error if you try from a browser? Try with http://[address]:3689/rsp/stream/37484 |
|
ffmpeg version 6.0 Copyright (c) 2000-2023 the FFmpeg developers It does not play and I get the same error if I try from a browser. I also noticed that the Soundbridge shows the song info as "Kind:WAV audio file" and "Bit Rate: 1411 kbps" for FLAC files which is not what I would expect. |
|
Ok, I found the reason it's not playing in the browser. I'll get back to you with a new attempt. |
|
I've pushed a commit to the branch that I think should fix at least playback in browser. Please test and let me know. |
|
I won't be able to test until Wednesday.
…On Sat, Oct 28, 2023, 8:30 AM ejurgensen ***@***.***> wrote:
I've pushed a commit to the branch that I think should fix at least
playback in browser. Please test and let me know.
—
Reply to this email directly, view it on GitHub
<#1665 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APETTJUHWGXWH76DC27DLDLYBUQJHAVCNFSM6AAAAAA57G5SBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBTHA2DQOBYGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
The Soundbridge is unable to stream. It still shows shows the song info as "Kind:WAV audio file" and "Bit Rate: 1411 kbps" for FLAC files. I can stream to my web browser.
|
|
Ok, that's progress then. It could sound like the Soundbridge gets some metadata that makes it expect wav, so I will check what is sent to it before streaming. |
|
I see the RSP playlist response returns info about the media format, so now I made a change so that the response instead tells the Soundbridge that it is 256 kbit mp3. Please try again with the latest commit from the branch included. |
|
It works perfect. |
|
Excellent. Does seeking also work? To change the implementation from experimental to actual, I have to decide which clients should get what formats. In the branch, all clients get 256 kbit mp3, even iTunes (haven't tested if it works, though). I would like to set some good defaults, so that configuration generally isn't needed. I am always weary about adding config options. What defaults do you suggest for RSP? |
|
The Soundbridge does not support seeking, only next and previous tracks and that does work. For bit rate default, I would suggest 320kbps. That's what I've been using with mp3fs for a while now. I used to frequent the Soundbridge forums and there were never complaints about mp3 bit rates needing to be reduced that I recall. May as well maximize sound quality. Are there other default settings you are asking about? To be clear, I am interested in this feature so that I can set wireless Soundbridges to receive 320kbps MP3 and wired Soundbridges to receive 1411kbps WAV. I have been thinking if the default should be 320kbps MP3 to insure that owntone will work with all Soundbridges regardless of type of network connection. |
|
Agreed 320kbps is a good default. Lots of literature to say that it's the level where its almost impossible to hear any difference from lossless files. It's also the most common mp3 format to download online. |
|
While looking at how to do this, I came across this which seems to imply that the Soundbridge supports ALAC. Do you know if that is the case @frankusb? If so, would it be a better alternative? You would get lossless, but with less compression than the 320 kbps mp3, so requires more wifi bandwidth (I think the compression is about 50%, so half of 1411 kbps I guess). |
|
You tried ALAC transcoding previously. I also found that the Soundbridge could not handle ALAC over wireless reliably by dropping some ALAC files in owntone. |
|
I've been working some more on this, trying to make it more clean/less hardcoded, so that it can be merged. If you have the opportunity, please give the current rspmp3 branch a try again and let me know if it works. |
|
It compiles and the Soundbridge plays fine. I'll leave it running and let you know if I notice anything. |
|
I did notice that the file size shows the FLAC size rather than the MP3 effective size in the Soundbridge song info. If I recall correctly, it also did this with WAV trans-coding as well. It doesn't affect anything that I can tell. |
|
I've now merged the change into master. It should also show the correct file size now. |
|
Do I understand correctly that there is nothing selective about this? All RSP will be 320kbps? |
|
Yes, indeed. Also DAAP, actually. I didn't add an option because in general I think mp3 is a better option than wav. Of course there is a slight quality loss, but wav could also be said to have that when the source was resampled to 44100. Another possible downside of mp3 is that the encoding requires cpu, but I figure that isn't much of problem these days. One issue with mp3 that occurs to me now is that some installations might not have the encoder (I think it's only in "libavcodec-extras"?). I will look into adding something that checks for that. |
|
Ripped CDs stored in FLAC format have zero quality loss transcoding to WAV at 44100 for the record unless there is something else I am unaware of in the transcoding from FLAC to WAV. The slight quality loss is only necessary for the wireless Soundbridges. Wired can have bit perfect playback. And to be overly pedantic, only the M500, M1000 and M2000 have a codec that can play 44.1kHz. For M1001 and R1000, the audio codec can only do 48kHz. For best quality, one would transcode for those to 48kHz as the 400MHz Blackfin in the Soundbridges have audible artifacts upsampling from 44.1kHz to 48kHz. If one wanted to be able to provide theoretical best quality, each individual device would need control over transcode output (WAV or MP3) and sample rate (44.1kHz vs 48kHz). |
|
Yes, agree. What would you suggest as selection strategy? It should preferably be with no configuration, or at least as little as possible. |
|
Well, you can't tell if a connection is bandwith limited (wireless), can you? It may be possible to determine the model and if so the optimal frequency could be selected. M500, M1000, M2000: 44.1kHz. M1001, R1000: 48kHz. Actually for R1000, it's only wireless so it could be MP3 320kbps 48kHz and it's optimal. The M models can be either wired or wireless so I think would require user configuration to optimize. |
|
By adding timers it might be possible to detect network and encoding bottlenecks, but it would be quite complicated and certainly nice to avoid. Reaction to an identified bottleneck would also be complex. I'm not sure how much the Roku's reveal about themselves, but I've made a branch where the request headers are dumped to the log. If you have some of these devices then please try the branch I'm thinking I should make another attempt with ALAC. Seems like it could be a silver bullet. |
Scratch that, now I see you said before that "I also found that the Soundbridge could not handle ALAC over wireless reliably by dropping some ALAC files in owntone." |
|
I've tried ALAC at my house and my parent's house and it's better than WAV but still has dropouts. That and you said ffmpeg didn't support FLAC to ALAC transcoding. Unfortunately, it appears the headers you captured are not unique between models (at least M2000 and M1001). |
|
Yes, everything seems to be resolved except for the false start. Is this expected? |
|
I'm not sure what to make of that. As you can see, the Soundbridge seems to be streaming a bit, then hanging up and then reconnecting and asking for "Range header: bytes=144-". Can you try with an actual ALAC file for comparison? I wonder if it does the same. |
|
Good test, it does similar. Bad news is there appears to be another problem. When I removed a FLAC file to replace it with an ALAC, it seemed to drop all songs. After that the cache was no longer used. A subsequent restart then added them all back and started preparing headers. |
Just so I reproduce in the right way: How exactly did you remove/replace? And the server was running, right? |
I copied the FLAC to another directory not monitored by owntone, ran ffmpeg to create an ALAC, copied the ALAC to the directory monitored by owntone, then deleted the FLAC leaving only the ALAC. Owntone was running the entire time. I was unable to reproduce myself but thought I better report it. |
|
I could reproduce the problem with the headers being dropped, and I believe it should now be fixed. |
|
I've got it compiled and will switch to ALAC for the wired Soundbridges. |
|
ALAC headers finished this morning. I'm getting a lot of Soundbridge reboots. It is reproducible, the same song will always cause the Soundbridge to reboot if I try to play it. Some songs do play normally. |
|
I did some more tests. I would assert my headers are corrupt for some files.
resulted in an unplayable file in VLC. MediaInfo showed it was truncated.
resulted in a playable file in VLC and no truncation in MediaInfo |
Not completely related to your situation, however, in my experience, I rarely had good result converting to ALAC with ffmpeg. For that, I use a script I created for This is the script I use: #!/bin/zsh
# Format flags
flags=([16]=1 [20]=2 [24]=3 [32]=4)
# Retrieve the bit depth of the audio file
depth=$(afinfo "$1" | sed -n 's/.*depth: I\(.*\)/\1/p')
# Convert the audio file
echo "Converting $1"
afconvert -f m4af -d alac/${flags[depth]} "$1" "${1%.*}.m4a"You'll have to retag your files afterwards. |
|
@frankusb good idea using "touch" to recreate the header and then checking again. To me that indicates a bug in the cache storage/retrieval of headers. I will see if I can catch it. |
|
@ejurgensen if you are not interested in any of my present xcode database information I was planning on removing it this weekend and rebuilding to see if the changes over time contributed to the current state or if there is something in the current codebase. I could always preserve it if you feel it might be interesting later. |
|
I haven't gotten around to looking at the latest issue yet, so not sure how much more information I might need. If you currently have a file which doesn't play due to invalid header, I think it would be great if you could save that invalid header. I think you can do that like this: Then just save the output. Then, when you have rebuilt, check if the new header matches. Also check if any other headers match:
|
|
I'm happy to leave the xcode database as is, weekends are just a good time to run the rebuild. |
|
Hi @frankusb I found a possible issue, so I've made some modifications to the branch that I hope you can test. Before doing so, you would have to delete your current xcode.db and rebuild. The rebuilding should be 4x faster now, since one of the modifications is to run the encoding in parallel. I've tried to do it in a way that hopefully doesn't make the server inoperable during the encoding, but let me know what your experience is. You can adjust the number of parallel jobs with CACHE_XCODE_NTHREADS. I tried testing the validity of the files with ffprobe, and they all pass, except for some special formats that can't be transcoded (e.g. due to DRM). If your Soundbridge still doesn't like some of the files, please check it with ffprobe, so I can see if that works as a test. |
|
I gave it a go. All good as far as I can tell. I can't find any problem files for the Soundbridge but will keep it set to ALAC. Some humble feedback. It might be useful to include the file for the above errors so one could correct/examine them. I happen to have 4 cores so your CACHE_XCODE_NTHREADS choice matches nicely. Querying the number of cores would probably be better. I could tell the system was sluggish but nothing stopped working. SCHED_IDLE vs SCHED_BATCH may help with this. |
Yes, I've added a fix for that now |
|
The fix did not trigger for me. I've checked to make sure the update is in my codebase, make, install. If I am reading the code correctly, make_mp4_header is not passing on the return value from read_decode_filter_encode_write back up to transcode_prepare_header. |
|
Seems to work ok when I mock the error: |
|
filter_encode_write can be called from decode_filter_encode_write and transcode_encode. Is it possible that only one return path results in the additional log message? I can't see why it's not in my log. On the bright side, I used a Soundbridge to play ALAC for 2-3 hours last night and it worked perfectly. |
|
Yes, you are right, there are some code paths that could lead to no logging of the file name. It seems to be when the encoder is flushed, but I'm not sure if that is the only way. I'll add some extra logging so we can check what is leading to it. |
|
I just noticed that WAV playtback is not working on the latest version of the rsp_daap_format3 branch. Sorry I took so long to notice, the problem only occurs at the very end of the first track played. When the Soundbridge buffers the next song during the end of the first track, it reboots. Once ALAC was working, I switched all of my wired Soundbridges to ALAC and never retested WAV. I should have left half in WAV and half in ALAC. I found this because I added a Soundbridge to my network and it defaulted to WAV. Switching it to ALAC allows it to play multiple tracks without rebooting. |
|
Thanks for the notice, it's great that you are testing. I haven't done much with the branch in some time, exactly because the changes are pretty extensive and thus need a lot of testing, otherwise merging into master will be too risky. I've also been busy with other things, but I haven't forgotten about this. |
|
ALAC and MP3 have been flawless on the most recent version of the branch. I've been using it exclusively. I've done lots of library changes, playlist changes and general usage. |
|
Good to hear. Also about the general usage, because it is also general regressions I'm concerned about. |
| Not directly related to the problem here, I'm wondering what is the advantage of streaming PCM audio (aka Wav files) instead of ALAC audio, which is also lossless? |
|
@hacketiwack ALAC saves network bandwidth over WAV is the only advantage from my perspective. This is mostly negligible though. @ejurgensen my general usage includes Airplay speakers (receivers actually), Apple remote control, Web interface remote control, Soundbridge RSP, and a little Chromecast speakers (they tend to cut off but always have). |
|
PCM/WAV has the advantage that it is decode only, so less cpu required, and also OwnTone can decode on the fly. With ALAC, OwnTone has to prebuild a cache of ALAC headers. This is cpu intensive and the cached headers do end up filling some disk space. |
I need to amend this report as it manifests on only one M1001 that I have found so far, it does not reproduce on an M2000 in WAV mode. Even more insidious, it appears to be length of track related, the M1001 plays a 0:52 song while in WAV mode but fails on 3:xx and 4:xx songs. I will leave all of my Soundbridges in WAV mode for a while to see if I can narrow this down. It's possible this is device specific? I tried on a second M1001 and it behaves the same. It appears to be model specific. |
|
It's a hard to say. A possibility is that there is something in the WAV header that the M1001 doesn't like, but that the M2000 accepts. The header has the length of the track, so that could explain why that makes a difference. Here's how the header is made fyi: https://github.com/owntone/owntone-server/blob/master/src/transcode.c#L439 |
Wireless Soundbridges can't handle WAV bitrates. Currently I have two instances of owntone running, one in conjunction with mp3fs to allow reliable playback on wireless Soundbridges. Besides the duplication of resources, the real annoyance is when I update a playlist, the mp3fs owntone then churns for 30-40 minutes re-reading all of the metadata since inotify is not supported with mp3fs.
The text was updated successfully, but these errors were encountered: