[ANNOUNCE] Squeezeslave: 1.2 released

[meercat]

I've just found squeezeslave & am trying it out, but I too get the behaviour where it hangs after a period of inactivity.

In fact, if I get to the end of a playlist without adding new songs, squeezeslave seems to hang.

I added the "-dslimproto" arg to the command line, and then find the "proto_sigpipe: MSG_NOSIGNAL" message in the output, and I've pasted the complete log output since the last of these messages below.
After this point the process seems to be pretty well hung (to the degree that a normal kill command won't stop it, but a kill -9 is needed).

This is squeezeslave v1.2-311 on 32 bit linux (kernel 3.2.12) built with gcc 4.5.3 running against a squeezeserver v7.7.2 - r33893.

squeezeslave 1.2-311 May 3 2012 10:49:09
compile flags: linux portaudio:1899 debug signals daemon aac
buffer sizes: decoder 2097152 output 2822400 bytes

with output devices:
1: (ALSA) HDA NVidia: HDMI 0 (hw:0,3) (11/46)
2: (ALSA) sysdefault (42/46)
3: (ALSA) hdmi (11/46)
* 4: (ALSA) default (42/46)
5: (ALSA) dmix (42/42)

and lsof shows the following sockets

*IPv4 2803002 * * *0t0 * * * *TCP linux2.local:40441->homenas:3483 (CLOSE_WAIT)
*IPv4 2803635 * * *0t0 * * * *TCP linux2.local:37675->homenas:9001 (ESTABLISHED)

If any more output would help - I could attach gdb & have a poke around, or whatever... just let me know

Hope you can help

Cheers

--
Tim // twitter.com/#!/schmerg


[[[ ... snip... ]]]
proto_send: cmd=STAT len=53
proto_sigpipe: MSG_NOSIGNAL
proto_stat: code=STMe decoder_buffer_size=2097152 decoder_buffer_fullness=0 rbytes_high=0 rbytes_low=17875107 output_buffer_size=2822400 output_buffer_fullness=0 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_stat: code=STMh decoder_buffer_size=2097152 decoder_buffer_fullness=0 rbytes_high=0 rbytes_low=17875107 output_buffer_size=2822400 output_buffer_fullness=0 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=audg len=24
proto_recv: cmd=vfdc len=174
proto_recv: cmd=strm len=30
proto_stat: code=STMr decoder_buffer_size=2097152 decoder_buffer_fullness=0 rbytes_high=0 rbytes_low=17875107 output_buffer_size=2822400 output_buffer_fullness=0 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=0 rbytes_high=0 rbytes_low=18727075 output_buffer_size=2822400 output_buffer_fullness=2441216 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_recv: cmd=strm len=30
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_recv: cmd=strm len=30
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_timestamp=0
proto_send: cmd=STAT len=53
proto_recv: cmd=vfdc len=174
proto_stat: code=STMt decoder_buffer_size=2097152 decoder_buffer_fullness=2091408 rbytes_high=0 rbytes_low=21006891 output_buffer_size=2822400 output_buffer_fullness=2818048 elapsed_seconds=0 elapsed_milliseconds=0 server_t

[ralphy]

This is a non-standard build, you've enabled aac and are not using the supplied portaudio.

compile flags: linux portaudio:1899 debug signals daemon aac

[meercat]

This is a non-standard build, you've enabled aac and are not using the supplied portaudio.

compile flags: linux portaudio:1899 debug signals daemon aac

Ah - I'm a gentoo user so I'd installed it via that.

I had a dig thru the ebuild - hoping it was just a simple wrapper around your makefiles, but it's quite a rewrite

I can turn off aac with use flags (the way gentoo handles configuration of packages) but it seems the ebuild author has written the ebuild to forcibly use the gentoo portaudio package.

So I downloaded your prebuilt binary (linux26) and tried using that, but it seems to hang in a similar way.

And then I tried the source, edited the makefile to remove the -DUSE_SIGNALS_FOR_RESTART as mentioned in an earlier post (and commented out the -DINTERACTIVE and LIBS line for curses and lirc, and also removed them from the buildall call to gcc), and that seems to work better, but still if left idle for a few minutes it sometimes goes silent, and has to be killed and restarted to resume playing although not hung as before - it's still producing log messages and can be killed without a SIGKILL.

That version reports
compile flags: linux portaudio:1608 debug daemon renice

Any suggestions of anything else I can try, or do to help diagnose it?

Cheers

--
Tim

[ralphy]

Any suggestions of anything else I can try, or do to help diagnose it?

The audio output thread is most likely hanging.

I'd suggest working with trunk for starters which is currently at r325.

I see no issues with the makefile changes, but you'll need to make them again for trunk.

Then I'd suggest updating the portaudio library version to r1826.

LIBPORTAUDIO=portaudio-r1826

[meercat]

The audio output thread is most likely hanging.

I'd suggest working with trunk for starters which is currently at r325.

I see no issues with the makefile changes, but you'll need to make them again for trunk.

I pulled the source for 325 and built that with minimal makefile changes as described earlier.

That played well for a while, but then the audio is lost again after an extended period of idle (still lots of log messages, so it's getting data and doing something, but no audio output). Normal Ctrl-C will kill it.

Then I'd suggest updating the portaudio library version to r1826.

LIBPORTAUDIO=portaudio-r1826

This seemed to make things worse, it hung after the slightest break of a few seconds, and hung hard (no more log messages, needs sigkill to kill it again).

If I can do anything to help, let me know, but if there's something wacky about my system & you've got your hands so full with other tasks that this comes some way down your list of priorities, I won't be offended

Cheers

--
Tim

[ralphy]

If I can do anything to help, let me know, but if there's something wacky about my system & you've got your hands so full with other tasks that this comes some way down your list of priorities, I won't be offended

I've only ever seen or had reports of this issue with ALSA, never with Windows or OSX.

You could also try using a USB sound card if you have one handy to prove it's the driver for your sound card and not squeezeslave. I had one system running Arch Linux with a same "hanging" issue when using the internal sound card but when I ran the same binary with a USB sound card it worked perfectly.

Updating the ALSA snd_hda_intel kernel driver on this system fixed the hanging with the internal sound card.

[meercat]

I've only ever seen or had reports of this issue with ALSA, never with Windows or OSX.

I'd believe it - sound has always been a bit hit-and-miss on this system (and it's not a clean install, but the hardware and O/S have been continuously upgraded over the last 6 or 7 years or so).

The 325 version (with default portaudio) seems much better, and doesn't always lose the audio, so I can easily live with it for now...
I've got it starting as a service, so while it's not a hard-hang I can always restart the service easily enough.

But I'll let you know if it suddenly improves or worsens etc.

Cheers

--
Tim

[pdeoliveira]

Hello Ralphy,
First of all, thank you for your great job on SqueezeSlave.
I'm using it on a Linux box with an xmos multichannel reference design as a USB source.
I'd like to use it for 24/96 files, which is not currently possible. I've already look into the code, and it seems possible.
I have some programing skills and I'm ready to help. Maybe you already started some work on this subject and I don't want to make things twice.
So, please let me know what I can do.

Pascal

[ralphy]

Hello Ralphy,
First of all, thank you for your great job on SqueezeSlave.
I'm using it on a Linux box with an xmos multichannel reference design as a USB source.
I'd like to use it for 24/96 files, which is not currently possible. I've already look into the code, and it seems possible.
I have some programing skills and I'm ready to help. Maybe you already started some work on this subject and I don't want to make things twice.
So, please let me know what I can do.

Pascal

The original sources for squeezeslave were hard coded to support 16/44.1 everywhere so it's a major update to the
code. All timing and memory allocation calculations assume 16 bits and 44100Hz and the pcm decoder as well. I've
managed to add mono support for all the decoders except ogg, but that's really a hack and would likely need to be
removed as part of this effort. You'll need to search all the code to find the assumptions. I've tried to add FIXME
comments in the code when I've added any such assumptions myself, but Richard didn't always do that.

I think a variable would need to be added to the audio structure to track the sample rate of the current stream. A
couple of the decoders don't have a means to obtain the sample rate of the current stream, so that would need to be
added. SBS seems to always pass '?' for the sample rate so you can't use that. Ignore the AAC and WMA decoders as
I'm planning to rewrite them and they are not part of the official build anyway.

The portaudio code expects 44100 as well so there's been no thought in the design on how to change the hardware
sample rate if the next track is different from the current one. Also the device list code checks if the device
specifically supports 44100.

There's also issues with the buffer code that needs to be resolved. I've been working the another forum member to
help get squeezeslave ported to the empeg/rio car player. Ideally all buffer code needs to be replaced with some
sort of ring buffer implementation. I've looked at using the one included with the port audio svn trunk but it's
more work than I'm willing to put into squeezeslave at this time.

I think you'll find the buffering code will be the greatest hurdle to overcome and I suspect that increasing both
bit size and sampling rate will expose additional issues.

The pa_callback is tightly coupled with the buffering code and this will need to be addressed when replacing the
buffer engine. There should be no blocking function calls in the callback. However, currently there are three.
For the empeg port we've managed to remove two of them, but the last in the slimaudio_buffer_available call can only
be removed by changing the buffer code.

If you'd like to take a stab at it, I'm happy to help as much as possible with suggestions and testing.

A fellow forum member, lauret, has started the work and has provided a patch which partially works. I'd suggest getting in contact with him to obtain the latest version and attempt to co-ordinate you're efforts. I can create a branch on google code for the hi-res project.

Here's a quote from lauret regarding the current state

Well, I have taken a look at the code for a couple of hours, but I didn't really see a good starting point, so I started with replacing all the 44.100 and 44100 occurences with resp. 96.000 and 96000 in the slimaudio dir. With an altered custom-convert.conf (which was already in place because of 44.1Khz) it worked perfectly! No hiccups or stuttering. Then I tried the same with 192kHz, and hardcoded it into slimaudio. This also worked, but it maxed out my server (Atom) with 44.1kHz material. 96kHz and above worked, I guess that's an easier job for SoX. Still, 2/3's of my music is in 44.1kHz, the rest is 96kHz or 192kHz, thus this is for me not an acceptable hack... Also, the bits per sample remain 16-bits.

So, next step, how to keep track of the sample rate? I guess in the slimaudio_t struct? And where is squeezeslave able to detect sample-rate? In e.g. slimaudio_decoder_flac.c?

I haven't heard anything since then and I've made a lot of changes to squeezeslave trunk, which I'll be updating later this week with several more changes.

[ralphy]

I've uploaded new 32-bit linux ALSA test builds for ARM, Intel and MIPPS to google code.

These include an updated portaudio library which fixes invalid sample rate error on device open for inexactly clocked sound cards with up to a 1% deviation from 44100Hz sample rate.

If in the past you've tried to use a sound card that was listed with -L but caused squeezeslave to exit with the error

output_thread: PortAudio error1: Invalid sample rate

then those sound cards should now work with the latest builds.

NB: squeezeslave still only supports 16-bit 44100Hz +/-1% sample rate output.