After the latest alsa-lib update to alsa-lib-1.0.22-2.fc11 I no longer have any audio. The soundcard I'm using (M-Audio Audiophile 24/96) is still shown in the hardware tab in the sound preferences but it no longer has any outputs. Reverting back to alsa-lib-1.0.21-3.fc11 solves the issue and the output shows up again.
Please provide the information described at https://fedoraproject.org/wiki/How_to_debug_sound_problems . Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 382468 [details] output of "alsa-info.sh --no-upload" Attached you'll find the output of "alsa-info.sh --no-upload" (generated with a working alsa-lib). I also did a "yum remove alsa-plugins-pulseaudio" and switched audacious to alsa output which usually works but not with this update. Also the day before the reboot audio worked fine and the only audio infrastructure related package updated since then is alsa-lib according to the yum update log. I also checked the mixer and routing using both alsamixer and the envy24control tool.
Does 'aplay -v -D plughw:1 <some_wav_file>' command work? Also try 'LIBASOUND_COMPAT=yes aplay -v -D plughw:1 <some_wav_file>'.
Created attachment 382487 [details] Screenshot of my Audio Preferences I am attaching my Audio Preferences (in Spanish). I don't know which profile was selected before updating, because it all worked perfectly since the install. I just know that after updating this package I lost the sound in my system, for listening or recording. I looked in this Preferences dialog and the fourth option was selected: Digital Stereo (IEC958) Output + Analog Stereo Input. I reverted the update but nothing changed. At last, I changed my profile to the last option: Analog Stereo Duplex, and everything works fine again. Perhaps this is casual and is not related, but maybe can help.
Benjamin: your issue is not the same, and is likely in PulseAudio, not alsa-lib. That setting should always default to analog out, not digital out. Can you please file a new bug against pulseaudio with all the info requested at: https://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I think I have the same issue (with the same card), and i have reported here : https://bugzilla.redhat.com/show_bug.cgi?id=499435 with the output of pulseaudio -vvvv Everything was working fine with the configuration of comment #29 in that bugreport, and since the last update, i don't have any "outputs" in the preferences (hence no sound with pulseaudio...) Moreover, with the /usr/share/alsa/cards/ICE1712.conf file with options for front : ICE1712.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type route ttable.0.0 1 ttable.1.1 1 slave.pcm { type hw card $CARD } slave.format S32_LE slave.channels 10 } pulseaudio won't even load (before, it was only with these options that i was able to make my card work), and i get an error when front is opened : pulseaudio -vvvv ... D: alsa-util.c: Managed to open front:0 pulseaudio: pcm_params.c :2237 : snd1_pcm_hw_params_slave: L'assertion « err >= 0 » a échoué. Abandon
Yes, it was the same problem for me. Reverting back to alsa-lib 1.0.20-1 solved the problem and I now have again digital input and output.
Guys, anyone is able to test commands in comment#3 ?
Created attachment 386483 [details] Aplay results
Commands tested, and put as an attachment. aplay -v -D plughw:0 <some_wav_file> did worked and I had sound.
Problem solved apparantly for me, with the help of the result of the aplay test... I now have pulseaudio working with the last alsa-lib. With the /usr/share/alsa/cards/ICE1712.conf like in comment #6 but with a change in /etc/pulse/default.pa (only the modified parts) : ### Load audio drivers statically (it's probably better to not load ### these drivers manually, but instead use module-hal-detect -- ### see below -- for doing this automatically) load-module module-alsa-sink device=plughw:0 tsched=0 load-module module-alsa-source device_id=0 tsched=0 #load-module module-alsa-sink #load-module module-alsa-source device=hw:1,0 #load-module module-oss device="/dev/dsp" sink_name=output source_name=input #load-module module-oss-mmap device="/dev/dsp" sink_name=output source_name=input #load-module module-null-sink #load-module module-pipe-sink ### Automatically load driver modules depending on the hardware available #.ifexists module-hal-detect.so #load-module module-hal-detect #load-module module-hal-detect tsched=0 #.else ### Alternatively use the static hardware detection module (for systems that ### lack HAL support) #load-module module-detect #.endif The only weird thing is that my card do not appear in pulseaudio manager, but the inputs and outputs are there and are functionning.
The point in my test was the 'export LIBASOUND_COMPAT=yes' environment variable setup. Please, check, if ICE1712.conf with channels=10 and original PA configuration file works with this setup.
Created attachment 386585 [details] Normal default.pas (with option tsched=0 as before) and libasound
With the PA configuration as before (that is to say only with the tsched=0 option, because it wouldn't work without this one), and with a export LIBASOUND_COMPAT=1 everything "seems" to go fine, that is to say my card is seen, the outputs (analogue & digital are there...), music plays fine and all. But as soon as i close the terminal.. pulseaudio disappear. How must I close the terminal once the pulseaudio configuration is done ? Another thing, where am I suppose to put this option ? In which config file... So that I can have the sound as soon as the computer starts. Thanks
alsa-lib-1.0.22-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/alsa-lib-1.0.22-2.fc12
alsa-lib-1.0.22-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/alsa-lib-1.0.22-3.fc11
Thanks a lot ! I'll update them as soon as possible from yum. So normally, pulseaudio should now work again without the LIBASOUND_COMPAT=1 option, and only with the "modified" default.pa including the tsched=0 option ? BTW, in another bug report : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4887#bugnotes , it was told to me that the tsched=0 was only a workaround and that pulseaudio should detect that automaticaly. Should that error be reported ? I think it was the content of https://bugzilla.redhat.com/show_bug.cgi?id=499435 but there has been no news... Thanks
it's a separate issue, but ALSA shouldn't 'detect it automatically', it should work correctly without needing to turn that feature off. Jaroslav, are you still asking for new reports for all systems which need tsched=0 workaround?
alsa-lib-1.0.22-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
alsa-lib-1.0.22-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
The problem has been resolved, and the analog outputs are back (with the tsched=0 option). Should the digital outputs be visible too with that configuration ? On another bug report, I was aked if you reverted this patch : http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=cd7070bf4b7afcdcd9dbde9d7363781aa3e1b581 In that case, this most likely would break audacious again.
Edit : Sorry, it's the digital outputs which are visible and the the analogue ones.
(In reply to comment #21) > The problem has been resolved, and the analog outputs are back (with the > tsched=0 option). Should the digital outputs be visible too with that > configuration ? > > On another bug report, I was aked if you reverted this patch : > http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=cd7070bf4b7afcdcd9dbde9d7363781aa3e1b581 Basically, yes, the new code is active only when 'export LIBASOUND_COMPAT=0' is set in the environmental variable. I need to figure where's the problem with this new code for ICE17xx based cards. > In that case, this most likely would break audacious again. I'm marking this bug as assigned to not forget to work on this issue later.
After upgrading to F13 and then to F14, I noticed that my system is still using alsa-lib-1.0.22-2.fc12. Apparently, it never got pushed to rawhide before F13 forked, and hasn't been pushed since. I can't check the F13 repo at the moment, but rawhide (F14) still has alsa-lib-1.0.22-1.fc13. Are there plans to push the fixed version past F12? Thanks, Gene
(In reply to comment #24) > After upgrading to F13 and then to F14, I noticed that my system is still using > alsa-lib-1.0.22-2.fc12. Apparently, it never got pushed to rawhide before F13 > forked, and hasn't been pushed since. I reported this inconsistency some time ago in bug 567627.
Thanks, Michal. I added myself to the CC list on #567627. There are several other packages that have the same issue. Is there an appropriate place to post my list, or should I file a bug on each package? Gene
(In reply to comment #26) > There are several other packages that have the same issue. Is there an > appropriate place to post my list, or should I file a bug on each package? I think filing bugs is the right way. Thanks.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.