LPCM stream not supported? about gmrender-resurrect HOT 10 OPEN

@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.

from gmrender-resurrect.

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 ?

from gmrender-resurrect.

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.

from gmrender-resurrect.

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 [email protected] 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//issues/14#issuecomment-16864203
.

from gmrender-resurrect.

"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:

from gmrender-resurrect.

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 ?

from gmrender-resurrect.

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) =)

from gmrender-resurrect.

On Apr 23, 2013 9:07 AM, "gunbro" [email protected] 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 ?

from gmrender-resurrect.

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.

from gmrender-resurrect.

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).

from gmrender-resurrect.