MB_SubSonic
MB_SubSonic copied to clipboard
DSD Playback stops after 3 seconds on Subsonic and instantly on Airsonic
Describe the bug Transfer of music stops after 3 seconds or refuses to play at all.
To Reproduce Steps to reproduce the behavior:
- Go to http://www.2l.no/hires/ to pick up a demo file in DSD format.
- Add the file format to the lists of formats on your server, say Subsonic/Airsonic-Advanced.
- If no DAC that can do DSD is present go to Preferences > Player > Configure > then set DSD File Playback to Convert to PCM.
- Log in with MusicBee on your server, and try to play the file.
- On Subsonic: The music plays for a couple seconds and then craps out, MusicBee says the file is corrupt.
- On Airsonic the same thing happens but instantly, it does not play for a little but but instantly complains about the file. Note: On a local network to the same file, the file plays just fine.
Expected behavior File plays through the entire song with no problems. FooBar2000 with SACD Decoder and Subsonic on worked just fine for many years. Airsonic does not, and MusicBee does not have the same bugs that using an external player on Foobar, AIMP and others do.
Screenshots
Error in question:

Server (please complete the following information):
- OS: Debian 11
- Server: Subsonic and Airsonic-Advanced
- Version 6.1.6 Premium and 11.0.0-SNAPSHOT.20211218104643
Player (please complete the following information):
- Player: MusicBee 3.4.8033 + MB_SubSonic 2.33
- OS: Windows 11
- Browser: Firefox
- Version [e.g. 22]
Additional context So the main goal is just that things play again, Subsonic worked just fine with External Player and Foobar but Airsonic does not so MusicBee seemed my best bet. This plugin works great with Airsonic so far. Minus DSD of course.
@DutchComputerKid The file format does play in MusicBee directly, but does it play on Airsonic or Subsonic (e.g. from the web front-end)? In my environment, it does not.
Airsonic doesn't play anything back when I select this file, while others work. I don't have a Subsonic installation ready to test with at the moment.
It could be that the problem is not in the plugin side, but rather on the Airsonic/Subsonic server side instead. Indeed the plugin just asks the server to stream the file and optionally transcode it (if that option is enabled). If the server fails to do so, we can't do much about it from here.
Yeah browser playback of DSD formatted music is not supported, so like I said external player + foobar worked great for many years on Subsonic.
So I figured its odd that it would play a little bit and then crap out on Subsonic, no idea where in the chain the error pops up. Airsonic-Advanced as the server craps out instantly, so it could be a data transfer issue, it has more issues with things like that even with FLAC and the like.
So if the plugin does simply ask for the file to be sent just like external player then yeah this does seem like a transfer problem.
So if the plugin does simply ask for the file to be sent just like external player then yeah this does seem like a transfer problem.
That's right. In order for Subsonic/Airsonic to enable FLAC transmission, there are two main areas that need to be addressed. One is to improve processing speed, and the other is to fix flaws in MIME judgment. The reason Subsonic and Airsonic both fail and fail differently is probably due to slightly different implementations in multiple places that need to be fixed.
If we solve all of these, all FLACs on the above sample site will be playable without any problems. They were improved and tested on my fork. (Mainly focused on UPnP extensions, so external players are not maintained, but the streaming logic used for them is same)
Since 24BIT / 352.8kHz FLAC can be transmitted, it seemed that the support for DSD was only a MIME problem. So I tried a few things, but it didn't seem to work. But foobar's complaints change a bit. Not corrupt but not seekable.
Unable to open item for playback (Object is not seekable):
If specify the MIME used in the environment where DSD playback of DutchComputerKid was successful, it may be possible to play in that environment. Unfortunately, DSD streaming is not common, so there is no standard MIME and there are many device incompatibilities.
- One solution is to allow the user to specify the MIME used by device or apps, on server. This is the method used by MiniServer.
- Another solution is to give up direct transmission and perform PCM conversion on the server.
In short, the solution to DSF / DSD is not as easy as FLAC ... For now depending on the combination of devices and apps, it may be possible to play.
It could be that the problem is not in the plugin side, but rather on the Airsonic/Subsonic server side instead. Indeed the plugin just asks the server to stream the file and optionally transcode it (if that option is enabled). If the server fails to do so, we can't do much about it from here.
midwan's answer looks correct. Paradoxically, FLAC glitches are relatively obvious, and Subsonic's descendants can resolve them and send high-resolution FLAC to the common player and the player can play it (Direct transmission, transcoding, resampling are all possible). Surely DSF/DSD is a transmission issue as well, but it's a bit more difficult. Even observing proprietary products is scattered across different forms of solutions.
Mannn thats a lot, awesome!
In the meantime it does look more and more like a tranfer problem. Clients all crap themselves and Airsonic with --debug doesn't see anything wrong. The logs just say yes he's listening to this song now!
VLC crashes and I've even seen it complain 'Can't identify codec" and errors like that. Foobar's still broken, and all that says is just "Network error", whatever that means. AIMP has the same issues as Foobar, and its always the file transmission that breaks. No idea how or why!
I'm going to report all of this on Airsonic-Advanced's GitHub, see what they think of this.
And @tesshucom thanks so much for the info! I did not know MIME types were into play as well. For now converting DSD to PCM works as you suggested, so that's something.
If there is no problem with the MIME of the server, it will be a waste of time... So there is a relatively simple detection method.
- Get the FLAC stream URI with transcoding turned off. In other words, the URI when sending directly. You can get the stream URI by getting the m3u file with an external player and opening it with an editor.
- Get header information with
curl commandinstead of browser or player- If MIME of the flac file is audio/flac, foobar won't complain
- If the MIME is audio/mpeg or octet-stream, foobar may complain. That's what his 'corrupt' means. Perhaps he hasn't misidentified it...
- I saw such behavior for the first time on foobar2000.
- Wrong MIME doesn't necessarily hurt players. The codec judgment of the client application has various grounds such as extension, MIME, file header, UPnP property, etc., and depends on the implementation of the player. (It may be played without any problem depending on the player)
- Many other players may be able to fix the problem once it can be played correctly on foobar2000.
Finding out the MIME was a good point because using curl -v gave this:
< HTTP/2 200 < server: nginx < date: Fri, 07 Jan 2022 19:26:13 GMT < content-type: application/octet-stream < content-length: 170393927
Might explain why Foobar just sits there "Starting playback..." and then failing with the non-descript "Network error". Sooo, if the MIME type would instead be audio, I wonder if that would do the trick for at least playing back the file, not worrying about the looping issue...
Edit: Hooray'd a little too early, I tested the same file on Subsonic to see if it would MIME as an audio stream buuut...
< HTTP/2 200 < server: nginx < date: Fri, 07 Jan 2022 19:46:26 GMT < content-type: application/octet-stream < content-length: 170393927
Same thing. Hmmmmm
Looping is probably a secondary issue. Some players may retry as a post-processing of error behavior during a network stream. A common example is dealing with timeouts due to temporary overload. By the way, foobar2000 has a definite timeout process, and if you transcode a file that is too big, it may time out and give an error. However in this retry process, for simple implementations that do not branch exceptions well, it may look like a loop in the case of unexpectedly very short-term errors (such as mis-sending MIME due to a bug). Depends on client implementation.
No transcoding for this test, forgot to add that. Direct DSF file, since again, Subsonic plays but Airsonic does not. On both its not sending the audio MIME but as you said the octet-stream MIME. Yet since Subsonic plays, maybe that's not the issue....
Regarding MIME of FLAC and DSD, I think the issues are different and independent issues.
- If the return MIME is application / octet-stream, it is likely that the server is not expecting to send that file format. DSD is a particularly special format, so it's a good idea to check with your product owner to see if you plan to officially support it.
- In other words, for both Airsonic and Subsonic the operation is not guaranteed.
- The reproducibility is a big issue. If there is a software playback environment or settings that can be reproduced independently of a specific device, it may be easier to get collaborators by providing information. It will be difficult to exchange opinions and proof unless everyone can reproduce the reproduction.
- If MIME of FLAC is not returned correctly, it may be a bug. Because, the definitions exist, in the case of airsonic. L58. MIME decisions are clever, but creating reproducible cases isn't too difficult.
@midwan, @DutchComputerKid
Sorry, I went off the track (It ’s not a completely unrelated story, but...). I agree with midwan's view on the original question of this issue.
https://github.com/midwan/MB_SubSonic/issues/64#issuecomment-1003704052
As far as I know, any information will be provided if requested. But most of the topics are not issues with MB_SubSonic...