asound.conf not honoured
Brought to you by:
sobukus
my /etc/asound.conf configuration is not honoured by -t alsa.
I have to use "-t alsa -a sysdefault" to make mpg123 work with alsa at all (or default but that says
Warning: You triggered the NtoM drop-sample resampler inside libmpg123.
Warning: You could trade CPU for quality by forcing a supported output rate.
My asound.conf is
pcm.!default {
type plug; slave.pcm { @func getenv; vars [ ALSAPCM ]; default "xmix"; }
}
ctl.!default { type hw; card 0; }
#pcm.xmix {
# type dmix
# ipc_key 1024; ipc_gid audio; ipc_perm 0660
# slave { rate 48000; periods 256; period_time 0; period_size 2048;
# buffer_size 16384; pcm "_xmix"; }
## slave { rate 44100; period_size 8192; pcm "hda_intel"; }
#}
#pcm._xmix { type hw; card 0; }
pcm.xmix {
type dmix
ipc_key 1024; ipc_gid audio; ipc_perm 0660
slave {
#rate 48000; periods 256; period_time 0; period_size 2048; buffer_size 16384
pcm "hw:0,0" }
}
pcm.bt {
type plug
slave.pcm { type bluealsa; device "00:F4:8D:33:38:FA"; profile "a2dp" }
hint { show on; description "ptv, Frau Antje Bluetooth" }
}
ctl.bt { type bluealsa }
My --list-devices say
Devices for output module alsa:
null Discard all samples (playback) or generate zero samples (capture)
bt ptv, Frau Antje Bluetooth
sysdefault:CARD=PCH HDA Intel PCH, ALC236 Analog Default Audio Device
front:CARD=PCH,DEV=0 HDA Intel PCH, ALC236 Analog Front output / input
surround21:CARD=PCH,DEV=0 HDA Intel PCH, ALC236 Analog 2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=PCH,DEV=0 HDA Intel PCH, ALC236 Analog 4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0 HDA Intel PCH, ALC236 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0 HDA Intel PCH, ALC236 Analog 5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0 HDA Intel PCH, ALC236 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0 HDA Intel PCH, ALC236 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
hdmi:CARD=PCH,DEV=0 HDA Intel PCH, HDMI 0 HDMI Audio Output
hdmi:CARD=PCH,DEV=1 HDA Intel PCH, HDMI 1 HDMI Audio Output
hdmi:CARD=PCH,DEV=2 HDA Intel PCH, HDMI 2 HDMI Audio Output
hdmi:CARD=PCH,DEV=3 HDA Intel PCH, HDMI 3 HDMI Audio Output
hdmi:CARD=PCH,DEV=4 HDA Intel PCH, HDMI 4 HDMI Audio Output
Which version is this?
We use the device named 'default' by default. I though that's proper behaviour … and it seems it usually is.
My
--list-devices
on an Ubuntu box says:You got a sysdefault, but no default. But anyway, it should work when you specify
-a sysdefault
. And it does, doesn't it?The message you get is about the chosen device enforcing a certain sample rate that does not match the input file (likely 48000 Hz vs. 44100 Hz). Mpg123 resamples on the fly with a low-quality algorithm. If you explicitly tell mpg123 to resample via the
-r <rate>
parameter, it will use a better resampler unless you force the low-quality algorithm via--resample NtoM
.I have seen the code snippet you show.
I never programmed ALSA. But thing is (sorry that the only remaining mp2/mp3 file on my box, from the 1000dokumente of german history)
However $ALSAPCM=bt and no BT currently active, so other audio programs i have to start with "ALSAPCM=xmix PROG FILE". Not mpg123.
-a sysdefault yes, but not libasound's /etc/asound.conf.
Actually it works even without -a sysdefault.
It seems yesterday it was so loud all around that i did not hear the first invocation's output. Then i looked due to that with the other noise reduced, but already with -o alsa, and then the rest with additional -a's.
Still asound.conf (and my $ALSACPM thing) is not honoured even though mpg123 uses libasound.
It is a pity that type bluealsa cannot sit under type dmix, but that is off-topic.
So sorry for all the noise all around. But i leave this open. (I could not close it anyway.)
Did you actually use
-t alsa
before? Because-t
does something very different from-o
.Anyhow … right now I do not understand how asound.conf is not honoured. Can you explain to me what should happen when? My work with ALSA setups is some time away. The main case should be that 'default' chooses the device you'd expect as default output device.
Does the issue still persist or was this also a misunderstanding?
Hello.
mpg123 is flaky regarding this.
Definetely, with "mpg123 -o alsa -a sysdefault" the problem does not happen.
With "ALSAPCM=xmix mpg123" 9 of 10 fail (after some time)
There is an element of chance if it works or not?! That is troubling. The failure is the error in writing, yes? But the selection of the correct audio device works with either
-a sysdefault
or the environment variable? What output is mpg123 using without any option?null
?Yes! I tell you what i have compiled with DEBUG and XDEBUG only in libout123 just five minutes ago, but now too late (will be 5am until i am for sleep), so more in detail tomorrow, ok.
But what i can tell you is that even "-o alsa -a sysdefault" sees the error, and it starts early like "for without", but with the args it continues, look:
Compare this with "without":
But wait. If i check against EAGAIN not only EINTR in out123_play(), then we go!
Question is: why do i reliably run into the "if(written < block" case without the arguments, whereas with the arguments it seems the block is fully written when we come to the condition?
P.S. (for now): this 1168 bytes. Could it be that without exact device info a different block size is chosen? Just a thought
Thanks for this investigation. This is another location that needs this check, apparently (compat/compat.c, unintr_write()):
Good catch. So if you added EAGAIN, things work? This looks like a simple fix I should release quickly.
Yes. Thanks for the patience.
Cool. So I added a fix to svn trunk. Can you verify that the current https://mpg123.org/snapshot works for you (if you read this after 0300 CEST, in about 3 hours from now).
Yes, works :)
Ciao!
Eh this is funny … by accident, the recent snapshot did not containt he fix, actually! I just now properly included it in trunk and triggered generation of a new snapshot.
Can you verify again that
Sorry for the confusion.
Hello. Actually i did not use the snapshot, but came over SVN over a branch called "multinet" or something like this. I had to do autoreconf -vis but on CRUX Linux all this is anyway there, so no problem. I did a diff- too, because you talked about two places where the fix is needed, but the diff contained only one. The fix was definetely in this thing.
Ciao!
How crafty. Yes, the fix landed in the multinet branch first.