crashes when the sound card is busy

[antonellocaroli]

Why does squeezelite crash when the sound card is in use? I remember it wasn't like this before...or am I remembering wrong?

squeezelite -C 1 -W  -o hw:CARD=D90,DEV=0 -r 44100-768000  -b 2080:3528
[09:14:52.230581] test_open:281 playback open error: Device or resource busy
[09:14:52.230819] output_init_common:401 unable to open output device: hw:CARD=D90,DEV=0

[ralph-irving]

I don't see a crash. Squeezelite can't open an alsa hw: device if another program already has it open, it never could. You need to use plughw: or one of the other alsa provided "virtual" devices.

[antonellocaroli]

you don't see the crash because it's on the command line, but the init service clearly crashes....the strange thing is that I remember it working differently in the past....

[pms967]

Squeezelite can't open an alsa hw: device if another program already has it open, it never could.

when using "-C n" option, even if the device is currently busy, Squeezelite should start anyway (waiting for the device to be free before it can start playing, of course).

IIRC, it used to work that way (though I'm not 100% sure about it).

[paul-1]

Squeezelite always (has always) opens the device at startup. The -C x option only releases the device after it's already running and not in use.

FWIW: Crash is different than a program terminating as expected when encountering an error condition.

[pms967]

Squeezelite always (has always) opens the device at startup. The -C x option only releases the device after it's already running and not in use.

Well... if it is so, that behavior should be changed.

In most cases, one want Squeezelite to be started automatically (and reliably) at system boot.

Thus (at least when the "-C n" option is given) Squeezelite should start and keep running unconditionally, no matter whether at that moment the configured audio device is busy or possibly does not even exist (yet).

When the system startup sequence try to start Squeezelite there may be other software which are temporarily occupying the configured device, or that device may possibly not even exist yet, as may happen when using external audio interfaces (which may possibly be plugged in or turned on lately). With the current behavior, Squeezelite would exit immediately... causing the system to fail to behave as the user would want and expect.

Rather than exiting, in such cases Squeezelite should instead just output a warning (complaining about the busy or missing device) and keep running, waiting for the configured device to become available. So that as soon as the audio device become available the system begin to work as expected, without any manual intervention.

[Braklet]

Squeezelite needs to remain small and dedicated to high quality LMS streaming, not become a general system resource manager.  I've seen too many projects get sidetracked into oblivion by trying to internally handle every possible outcome.

You can manage soundcard resources through external scripting if "run once and forget it" is a primary objective.

On Tuesday, November 2, 2021, 11:19:38 AM EDT, pms967 ***@***.***> wrote:  

Squeezelite always (has always) opens the device at startup. The -C x option only releases the device after it's already running and not in use.

Well... if it is so, that behavior should be changed.

In most cases, one want Squeezelite to be started automatically (and reliably) at system boot.

Thus (at least when the "-C n" option is given) Squeezelite should start and keep running unconditionally, no matter whether at that moment the configured audio device is busy or possibly does not even exist (yet).

When the system startup sequence try to start Squeezelite there may be other software which are temporarily occupying the configured device, or that device may possibly not even exist yet, as may happen when using external audio interfaces (which may possibly be plugged in or turned on lately). With the current behavior, Squeezelite would exit immediately... causing the system to fail to behave as the user would want and expect.

Rather than exiting, in such cases Squeezelite should instead just output a warning (complaining about the busy or missing device) and keep running, waiting for the configured device to become available. So that as soon as the audio device become available the system begin to work as expected, without any manual intervention.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[antonellocaroli]

@Braklet your comment is not very understandable, what do you mean?

this is what happens with squeezelite version 1.8.4, one of the most minimal versions....

squeezelite-old -C 1 -o hw:CARD=D90,DEV=0 -r 44100-768000  -b 2080:3528 -d all=info
[18:06:43.085464] stream_init:290 init stream
[18:06:43.088326] output_init_alsa:889 init output
[18:06:43.088398] output_init_alsa:929 device : hw:CARD=D90,DEV=0 requested alsa_buffer: 40 alsa_period: 4 format: any mmap: 1
[18:06:43.088512] output_init_common:410 supported rates: 768000 705600 384000 352800 192000 176400 96000 88200 48000 44100 
[18:06:43.096532] output_init_alsa:946 memory locked
[18:06:43.097224] decode_init:129 init decode, include codecs:  exclude codecs: 
[18:06:43.097354] register_dsd:906 using dsd to decode dsf,dff
[18:06:43.097928] load_faad:610 loaded libfaad.so.2
[18:06:43.097971] register_faad:640 using faad to decode aac
[18:06:43.098867] load_vorbis:300 loaded libvorbisfile.so.3
[18:06:43.098915] register_vorbis:329 using vorbis to decode ogg
[18:06:43.099553] load_flac:266 loaded libFLAC.so.8
[18:06:43.099599] register_flac:294 using flac to decode flc
[18:06:43.099622] register_pcm:424 using pcm to decode aif,pcm
[18:06:43.100073] load_mad:383 loaded libmad.so.0
[18:06:43.100120] register_mad:412 using mad to decode mp3
[18:06:43.100749] discover_server:756 sending discovery
[18:06:48.105910] discover_server:756 sending discovery
[18:06:53.111197] discover_server:756 sending discovery

this with the current versions:

squeezelite -C 1 -o hw:CARD=D90,DEV=0 -r 44100-768000  -b 2080:3528 -d all=info
[18:09:48.735630] stream_init:370 init stream
[18:09:48.738440] output_init_alsa:939 init output
[18:09:48.738521] output_init_alsa:978 requested alsa_buffer: 40 alsa_period: 4 format: any mmap: 1
[18:09:48.741963] test_open:281 playback open error: Device or resource busy
[18:09:48.742064] output_init_common:391 unable to open output device: hw:CARD=D90,DEV=0
PlayerRpi /usr/bin #

in both cases the audio output is busy with MPD

clearly if I create an automatic startup service, the first one doesn't crash, the second one crashes....and then I'm forced to restart it manually....don't know if this is clear...I can't explain better....

[pms967]

Squeezelite needs to remain small and dedicated to high quality LMS streaming, not become a general system resource manager.  I've seen too many projects get sidetracked into oblivion by trying to internally handle every possible outcome.

may be you completely misunderstood what I meant. Which is nothing like you say. General resource manager? Not at all.

It's just a matter of not exiting immediately if the device which has been specified on the command line is not available, but instead keep running, waiting for that device to became available. That's it. Trivial.

There's nothing complicated or which may increase the size of the software.

[Braklet]

I'm sure Ralph will give your upcoming PR full consideration.

On Tuesday, November 2, 2021, 02:15:06 PM EDT, pms967 ***@***.***> wrote:  

Squeezelite needs to remain small and dedicated to high quality LMS streaming, not become a general system resource manager.  I've seen too many projects get sidetracked into oblivion by trying to internally handle every possible outcome.

may be you completely misunderstood what I meant. Which is nothing like you say. General resource manager? Not at all.

It's just a matter of not exiting immediately if the device which has been specified on the command line is not available, but instead keep running, waiting for that device to became available. That's it. Trivial.

There's nothing complicated or which may increase the size of the software.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[ralph-irving]

The attached patch should restore the previous behaviour.

Can you apply to the latest git sources to confirm? devicebusy.patch.txt

[antonellocaroli]

@ralph-irving thanks, this seems to work.

squeezelite -C 1 -o hw:CARD=D90,DEV=0 -r 44100-768000  -b 2080:3528 -d all=info
[06:28:46.978494] stream_init:454 init stream
[06:28:46.981360] output_init_alsa:936 init output
[06:28:46.981449] output_init_alsa:975 requested alsa_buffer: 40 alsa_period: 4 format: any mmap: 1
[06:28:46.981605] output_init_common:425 supported rates: 768000 705600 384000 352800 192000 176400 96000 88200 48000 44100 
[06:28:46.990879] output_init_alsa:1002 memory locked
[06:28:46.990972] output_init_alsa:1008 glibc detected using mallopt
[06:28:46.991556] decode_init:153 init decode
[06:28:46.991635] register_dsd:908 using dsd to decode dsf,dff
[06:28:46.992602] load_flac:310 loaded libFLAC.so.8
[06:28:46.992661] register_flac:338 using flac to decode ogf,flc
[06:28:46.992685] register_pcm:483 using pcm to decode aif,pcm
[06:28:46.993227] load_mad:396 loaded libmad.so.0
[06:28:46.993266] register_mad:425 using mad to decode mp3
[06:28:46.993857] discover_server:795 sending discovery
[06:28:51.997633] discover_server:795 sending discovery
[06:28:57.002921] discover_server:795 sending discovery
[06:29:02.004130] discover_server:795 sending discovery
[06:29:07.009422] discover_server:795 sending discovery

[ralph-irving]

Thanks for confirming. I've commited the fix.