I start audacious , I can play a single track. The moment I go to the next song, basically an alsa pcm close , called by re-open, the bug is triggered. audacious crashes with a message from glib about a invalid pointer. I have tried using the same pcm interface with aplay which does not crash (though it is only playing a single track; but aplay has to close the interface so if it was in alsa I would assume aplay would crash too. By this rationale I beleive the bug is in audacious/audacious-plugins). ===> SNIP: here is the smoking gun. *** glibc detected *** audacious: munmap_chunk(): invalid pointer: 0x0838f638 *** ===> SNIP: here is what I think is all of the relevant pieces from my .asoundrc defaults.pcm.rate_converter "samplerate_medium" pcm.aa { type plug slave { pcm NX format S24_3LE # format S16_LE channels 2 rate 96000 } # rate_converter "samplerate_best" } Reproducible: Always Steps to Reproduce: 1. setup the rate conversion pcm as shown in the details 2. play a track, im-between the end-points switch to a new track without stopping 3. watch audacious implode Actual Results: * JACK outputs 24 bit samples no problem as well as timidity. my investigation: I dug into the audacious code a bit before bed and noticed that audacious does alot of probing of the pcm it is using. This behavior is sensible for users who do not configure or precisely specify their sound setup, they just install and expect it to work. however when using "virtual" pcms especially rate converters what could possibly be returned ? the rate converter should convert whatever it gets to the target. There is no spec for the format/samplerate expected , only the target. Which makes sense. My last guess as to what was happening is that audacious is generating typical CD audio: S16_LE @ 44.1 kHz. the rate plugin is converting it to S24_3LE @ 48 kHz. When it probes the interface it gets the target spec and the memory manager blows up with bad offsets. This is a theory, I have only brushed on the surface of the alsa API. Stepping back from the details there are use cases where you do not want the auto-magical media-player. I want a dumb player with a good queue'ing interface, and a great alsa config. This is because the internal signal processing of audacious generates horrible audio, high noise , and dumps the volume so bad my Grado amp has to be turned all the way up to generate a low listening volume. With libsamplerate tuned correctly the system sounds spectacular, and all my apps can use the high quality signal path as long as they aren't a monolithic be-everything app. Getting to the point this is a great case for gentoo use flags. It could be conditionally compiled to minimize the probing/signal processing, and use flags could make it work cleanly for different use cases. In looking at the code this looks like an ordeal. The assumptions about how the player is used are all over the code, there are three forks in the codebase: xmms_ bmp_ and audacious. Any such effort would be so invasive it would probably end up being another fork. Assuming that my theory that the probing is returning the target of the resample is correct, it is likely the only practical solution that comes to mind is to feature enhance alsa with a input spec it can return when probed.
Created attachment 105617 [details] gdb backtrace after crash
Created attachment 105621 [details] full audacious output on crash
Created attachment 105623 [details] emerge --info
software versions: adacious: 1.2.2 audacious-plugins: 1.2.5 alsa-{lib,plugins}: 1.0.14_rc1
Turned on the debugging and received this on standard output. It appears that the probing is correct and it is detecting the plug correctly. ===>SNIP Card 1, Device 0, Subdevice 0 start_mode: DATA xrun_mode: STOP tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 2205 xfer_align: 2205 silence_threshold: 0 silence_size: 0 boundary: 722534400 Plug PCM: Rate conversion PCM (96000, sformat=S24_3LE) Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 2205 period_time : 50000 tick_time : 1000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 2205 xfer_align : 2205 start_threshold : 19845 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 722534400 Slave: Hardware PCM card 1 'SB Audigy 2 NX' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S24_3LE subformat : STD channels : 2 rate : 96000 exact rate : 96000 (96000/1) msbits : 24 buffer_size : 48002 period_size : 4800 period_time : 50000 tick_time : 1000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 4800 xfer_align : 4800 start_threshold : 43200 stop_threshold : 48002 silence_threshold: 0 silence_size : 0 boundary : 1572929536 ===>SNIP Digging deeper I then found this output from the alsa plugin. device: aa fmt 5, channels: 2 alsa_setup_mixer alsa_get_mixer alsa_setup_mixer(): Failed to find mixer element: NX Opening device alsa_setup Opening device: aa Device setup: buffer time: 500000, size: 88200. Device setup: period time: 50000, size: 8820. bits per sample: 16; frame size: 4; Bps: 176400 Closing device This narrows it down to src/alsa/audio.c, the alsa_close function as the last known point before the crash. I should have more info pretty soon. lines 270-277 look really fishy. There are three glib_free calls right after xmms_convert_buffers_destroy. also the grand finale crash message has changed slightly with a bit more detail, a glib hacker might be able to glean something from it *** glibc detected *** audacious: double free or corruption (!prev): 0x08383698 *** I will see if I can refine it further
got a little bit further. Last line before the crash is 264 in audio.c I was stepping with next when it hit 264 ===> g_thread_join(audio_thread); looking into that thread I see in the error path the call to alsa_close_pcm which shows up in the backtrace which looks like it's taking the _error: path. I will keep digging but without knowing much about alsa or audacious it will be difficult to make much more progress.
Please read your einfos !!! use enotice or some alternative: ~/.asoundrc is DEPERCATED and ewarns DO WARN that they are likely to break apps !!! The name of your bug's title is the first proof you dont read them ! my /var/log/portage/media-libs\:alsa-lib-1.0.14_rc2\:20070209-01344 states: * Starting from alsa 1.0.11_rc3 the configuration for dmix is changed. * Leaving around old asound.conf or ~/.asoundrc might make all apps * using ALSA output crash. * Note that dmix output is enabled by default on the 'default' device * since ALSA 1.0.9. and next time, also giv your absolute path: ".asoundrc" is implicitely in ~/ . Now please close your bug yourself. AND READ ENOTICES.
Several people seem to agree that this is not an audacious bug. Should you disagree, please take this bug report upstream. The URL has been added on the bug for your convenience.
