FS#60579 - [alsa-?] Various alsa packages 1.1.6 => 1.1.7 breakage for simultaneous usage
Attached to Project:
Arch Linux
Opened by brent saner (sanerb) - Thursday, 25 October 2018, 08:30 GMT
Last edited by Doug Newgard (Scimmia) - Sunday, 04 November 2018, 21:34 GMT
Opened by brent saner (sanerb) - Thursday, 25 October 2018, 08:30 GMT
Last edited by Doug Newgard (Scimmia) - Sunday, 04 November 2018, 21:34 GMT
|
Details
Description:
Bear with me, as I'm not entirely sure which package *exactly* it is. I do know that it occurs on alsa packages 1.1.7, and did not on 1.1.6. On October 4th, 2018, my system's audio functioned normally. Specifically, I could (simultaneously): - Record in Audacity - Use Mumble (in "continuous" mode) However, after applying updates on October 24th, 2018, I notice that: 1.) I no longer see a "default" input nor output device in Audacity (which would be the pulseaudio, etc.) 2.)a.) Sometimes, the microphone device does not show up at all in the Input source selection dropdown in Audacity. 2.)b.) Sometimes, the speaker device is set to the microphone('s monitor?) device. 3.) Sometimes, I can manually set the microphone and speaker device for input/output. I can record as normal in Audacity. However, as soon as I use another application which also has access to the soundcard (I am unclear on the exact specifics here, but it seems to be for any usage - input or output), if I then attempt to record in Audacity I get an error message (in Audacity) stating: Error opening recording device. Error code: -9985 Device unavailable. If there's any further information I can provide or if you need stdout/stderr/journal/dmesg/strace for Audacity, let me know. I recognize it sounds a little confusing. Additional info: Affected package(s) include(s) one or more of the following: alsa-lib-1.1.7-1 alsa-plugins-1.1.7-1 alsa-utils-1.1.7-1 lib32-alsa-lib-1.1.7-1 lib32-alsa-plugins-1.1.7-1 Based on the seeming relation to pulseaudio (see Workaround below), I'm going to hazard a guess that it's alsa-plugins (or possibly lib32-alsa-plugins). Steps to reproduce: See description. Workaround: I have found, after much finagling, that this *seems* to work. 1.) Install the latest 1.1.6 versions of the above packages. 2.) pulseaudio -k (using GNOME) (for some reason, a reboot seemed to have no positive effect; a pulseaudio -k was required from a running session instead) |
This task depends upon
Closed by Doug Newgard (Scimmia)
Sunday, 04 November 2018, 21:34 GMT
Reason for closing: Duplicate
Additional comments about closing: FS#60591
Sunday, 04 November 2018, 21:34 GMT
Reason for closing: Duplicate
Additional comments about closing:
1) with alsa-lib 1.1.6 installed, audacity lists "pulse" and "default" as available playback devices.
2) with alsa-lib 1.1.7 installed, audacity does not list "pulse" and "default" as available playback devices.
Simply starting a new instance of audacity after switching versions seems to show the different behaviour, no need to kill pulse.
It seems audacity isn't getting the full list of playback devices for some reason, and it also seems that it is only audacity that is affected.
Attached are some logs showing the difference in output from audacity starting up with the different versions, and the debug messages printed by pulseaudio when the latter happens.
pulse-output-1.1.7 (28.4 KiB)
audacity-1.1.6 (11.7 KiB)
audacity-1.1.7 (11.4 KiB)
This may sound like an edge case, and requires modifying packages from their arch-repository versions, but this will be a serious problem for some users, like me, who have their computer hooked into a digital surround sound system.
When installing alsa-lib and alsa-plugins 1.1.7, the digital output will fail to initialize. It is normal for this to happen after upgrading alsa-plugins in Archlinux, as the [extra] package isn't built against ffmpeg (dependency of the a52 plugin), possibly due to licensing restrictions (AC3 is non-free).
Normally this could be fixed by building the package againt ffmpeg, but I found it also necessary to modify the ffmpeg package this time, which has dropped libavresample (dependency of the rate plugin; dependency of the a52 plugin), by appending "--enable-avresample" to configure.
After buiding alsa-plugins against ffmpeg with libavresample, the a52 plugin built but still would not load. pulseudio reported "(alsa-lib)pcm_rate.c: Unknown field card"; as if the syntax for asound.conf has changed. There does not appear to be any syntax that works with 1.1.7.
Downgrading alsa-lib and alsa-plugins to 1.1.6 restores functionality; not sure if it's a problem with either one or both packages.
This may sound like an edge case, and requires modifying packages from their arch-repository versions, but this will be a serious problem for some users, like me, who have their computer hooked into a digital surround sound system.
When installing alsa-lib and alsa-plugins 1.1.7, the digital output will fail to initialize. It is normal for this to happen after upgrading alsa-plugins in Archlinux, as the [extra] package isn't built against ffmpeg (dependency of the a52 plugin), possibly due to licensing restrictions (AC3 is non-free).
Normally this could be fixed by building the package againt ffmpeg, but I found it also necessary to modify the ffmpeg package this time, which has dropped libavresample (dependency of the rate plugin; dependency of the a52 plugin), by appending "--enable-avresample" to configure.
After buiding alsa-plugins against ffmpeg with libavresample, the a52 plugin built but still would not load. pulseudio reported "(alsa-lib)pcm_rate.c: Unknown field card"; as if the syntax for asound.conf has changed. There does not appear to be any syntax that works with 1.1.7.
Downgrading alsa-lib and alsa-plugins to 1.1.6 restores functionality; not sure if it's a problem with either one or both packages.
FS#60586r.e. a52 pluginFixed the problem with audacity for me, would be good to know if it works for python sounddevice.