search

hzeller / gmrender-resurrect

Resource efficient UPnP/DLNA renderer, optimal for Raspberry Pi, CuBox or a general MediaServer. Fork of GMediaRenderer to add some features to make it usable.
GNU General Public License v2.0
839 stars 204 forks source link

LPCM stream not supported? #14

Open gunbro opened 11 years ago

gunbro commented 11 years ago

When i try to listen music using foobar with UPnP MediaRenderer Output component (http://goo.gl/qwlSh) it doesent work with 16bit output 16bit

[UPnP] Stream address: http://192.168.1.109:49623/stream.l16 [UPnP] transport op: Play [UPnP] HTTP request: GET /stream.l16 [UPnP] Source: 192.168.1.111:53597 [UPnP] Connection: close [UPnP] Host: 192.168.1.109:49623 [UPnP] icy-metadata: 1 [UPnP] transferMode.dlna.org: Streaming [UPnP] User-Agent: GStreamer souphttpsrc libsoup/2.38.1 [UPnP] Serving LPCM [UPnP] Connection: close [UPnP] Content-Type: audio/L16;rate=44100;channels=2 [UPnP] TransferMode.dlna.org: Streaming [UPnP] User-Agent: Windows/7.0 UPnP/1.1 foobar2000/1.x [UPnP] Returned time: 0:00:00.000 [UPnP] transport op OK [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:00.000 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:00.000 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:00.000 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:00.000 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:00.000 [UPnP] Transport state: PLAYING [UPnP] transport op: Stop [UPnP] transport op OK

But if i change 16bit to 24bit it plays well

24bit

[UPnP] Stream address: http://192.168.1.109:49653/stream.wav [UPnP] transport op: Play [UPnP] HTTP request: GET /stream.wav [UPnP] Source: 192.168.1.111:51810 [UPnP] Connection: close [UPnP] Host: 192.168.1.109:49653 [UPnP] icy-metadata: 1 [UPnP] transferMode.dlna.org: Streaming [UPnP] User-Agent: GStreamer souphttpsrc libsoup/2.38.1 [UPnP] Serving WAV [UPnP] Connection: close [UPnP] Content-Type: audio/wav [UPnP] TransferMode.dlna.org: Streaming [UPnP] User-Agent: Windows/7.0 UPnP/1.1 foobar2000/1.x [UPnP] transport op OK [UPnP] Returned time: 0:00:00.000 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:02.887 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:07.952 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:12.961 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:17.983 [UPnP] Transport state: PLAYING [UPnP] Returned time: 0:00:23.000 [UPnP] Transport state: PLAYING [UPnP] transport op: Stop [UPnP] transport op OK

hzeller commented 11 years ago

Do you have a log output of gmrender-ressurect for this ? You see it if you run gmrender in the foreground.

It might be some trouble checking the mime-type. When you play 24 bit audio, the mime type is a standard "audio/wav", while in the 16bit case, your controller or server sets this to be "audio/L16;rate=44100;channels=2"

Some controllers check first if the renderer can accept a particular mime-type before sending it; for this to work, the renderer sends all the available mime-types at startup (you see these flying by relatively early in the gmrender log when it starts up). It might be, that the controller attempts to compare the full string and fails (as it will probably only send "audio/L16" or just "audio/wav" (which it is essentially the container for).

I know that BubbleUPnP has an option to skip checking the mime type, maybe there is such an option in your controller as well ?

gunbro commented 11 years ago

i create 3 logs:

  1. start log of gmrender , please look there are was some errors >> https://dl.dropboxusercontent.com/u/26402232/grender-start-log.txt
  2. audio/L16;rate=44100;channels=2 >> https://dl.dropboxusercontent.com/u/26402232/lpcm.txt
  3. wav >> https://dl.dropboxusercontent.com/u/26402232/wav.txt

seems gmrender must support audio/L16;rate=44100;channels=2 it shows: Registering support for 'audio/L16;rate=44100;channels=2' when i run it in the foreground.

hzeller commented 11 years ago

interesting in the logs: GStreamer: source: Error: Internal data flow error. Maybe the "conv: size 3909 is not a multiple of unit size 4" is related.

Looks like it gets the stream, but then has trouble decoding it. So either the stream is corrupted, or gstreamer has some other trouble. Mmh.

Do you always get this problem with 16 bit streams ? Is this stream coming from a file, or is it dynamically re-coded by the controller ?

On 23 April 2013 08:09, gunbro notifications@github.com wrote:

i create 3 logs:

  1. start log of gmrender , please look there are was some errors >> https://dl.dropboxusercontent.com/u/26402232/grender-start-log.txt
  2. audio/L16;rate=44100;channels=2 >> https://dl.dropboxusercontent.com/u/26402232/lpcm.txt
  3. wav >> https://dl.dropboxusercontent.com/u/26402232/wav.txt

seems gmrender must support audio/L16;rate=44100;channels=2 it shows: Registering support for 'audio/L16;rate=44100;channels=2' when i run it in the foreground.

— Reply to this email directly or view it on GitHubhttps://github.com/hzeller/gmrender-resurrect/issues/14#issuecomment-16864203 .

gunbro commented 11 years ago

"Do you always get this problem with 16 bit streams ?" I dont try any other programs to stream. Looks like foobar dynamically re-coded playlist in one big stream. How it looks when i using Foobar as controller and BubbleUPnP as renderer: bubble-as-renderer fobar-as-controller

hzeller commented 11 years ago

So looks like foobar and gstreamer disagree in the way the encoding should work. I don't have access to foobar (no Windows) to test this in detail. Would be interesting to try if this works with gstreamer1.0 (but that, again, is not commonly available as packages in RPi yet).

Is there a downside for now to just use 24 bit ?

gunbro commented 11 years ago

No, it not a problem completely to use 24bit. Your latest version dont work with foobar at all, until you changed something in it, its just shows XML response error.=) Maybe it start to work when you Merge pull request #13 from badfortrains/platinum-fix, i don't know, im totally noob in this stuff (Linux, github) =)

hzeller commented 11 years ago

On Apr 23, 2013 9:07 AM, "gunbro" notifications@github.com wrote:

No, it not a problem completely to use 24bit. Your latest version dont work with foobar at all, its just shows XML response error.=)

Uh, sorry, that is disturbing (can you file a separate bug for it?). Can you figure out with which version it started to fail (it is possible to sync to each individual submit wit git)

The pull request is already in, maybe it is the cause ?

gunbro commented 11 years ago

I mean your current version started to work with foobar (but only in 24bits for now). Older version shows XML response error. Sorry for misunderstanding, its because of my bad english.

hzeller commented 11 years ago

FYI, I had some access to a Windows machine and foobar2000 this weekend and could verify the XML problem. It looks like a bug in foobar2000 ( http://www.hydrogenaudio.org/forums/index.php?showtopic=101360 ) I had removed this Pull-request fix in the meantime because it looked odd, but now have re-added the workaround for this bug in foobar2000 again. Let's see if someone at the forum picks up the thread and tries to find out what happens.

From my brief experiments, it seems that foobar2000 is not very suited as UPnP controller as it always tries to re-encode the stream (which degrades quality and does not encode the song title, but it just is named "foobar2000 stream" or something) instead of just passing over the stream from the original UPnP source .. which is why we have that LPCM problem in the first place. Using 24Bits seems to be the way to go as it at least doesn't add inaccuracies.

I couldn't dig down to the LPCM 16-Bit problem itself yet though, because I had another problem actually getting the stream: for some reason, foobar2000 only gave me URLs of the form http://127.0.0.1:xxxx/stream.wav or something, which means that it pointed to localhost instead of the network location of foobar2000 - couldn't figure out if this was due to some firewall setting or some other Windows or foobar2000 oddity (still I got the commands via the network so that I could at least see the XML problem and saw the song-title).

bubbleguuum commented 10 years ago

@hzeller

That "conv: size 3909 is not a multiple of unit size 4" you mention is a gstreamer issue recently mentionned on the gstreamer bugtracker:

https://bugzilla.gnome.org/show_bug.cgi?id=689460

the gstreamer lpcm decoder is fed a buffer whose size is not multiple of 4 and fails with this error. this problem seems to never happen on x86 but do happen on ARM. Probably because on x86, read() always returns a number of bytes multiple of 4.

So LPCM decoding is broken on ARM.