I find that I'm wasting considerable time trawling through bug reports where comments not from the original reporter indicate experiences involving very different software configurations. For instance, person A files a bug against pulseaudio on default Ubuntu, and you see very similar symptoms on default Kubuntu and thus proceed to add some comments to the bug report.
File a separate bug.
The bug reporter's symptoms don't involve Phonon at all, but yours do. You've just splattered over an otherwise useful timeline, which generally makes me want to take a long springtime walk instead of fixing the actual bug. Thanks for understanding.
Showing posts with label audio. Show all posts
Showing posts with label audio. Show all posts
Tuesday, April 6, 2010
Thursday, October 29, 2009
Caveats for audio in 9.10
Here follows an update for 9.10 to this month's earlier caveats:
If you use Ubuntu:
If you use Ubuntu:
- Use Karmic's kernel, not Jaunty's. A lot of you with Realtek and IDT/Sigmatel HDA codecs are being bitten by /boot/grub/grub.cfg not being updated properly, resulting in Jaunty's 2.6.28 kernel being used instead of Karmic's 2.6.31. Jaunty's kernel has pretty subpar performance for PulseAudio, and you should not incorrectly blame PulseAudio.
- Check that slmodemd is not running if you're seeing a dummy/null sink in the volume control applet. Arguably PulseAudio's module-udev-detect should allow the device instead of bailing when detecting it, and an approach is under discussion for future versions. In the meantime, you can either instead load module-detect in /etc/pulse/default.pa (or ~/.pulse/default.pa) or kill slmodemd.
- Install linux-backports-modules-alsa-karmic (then reboot) if you have a very new computer, because that package enables audio on quite a few very new laptop models and contains much improved support for microphone auto-switching.
- Use a temporary alternate channel mapping for PulseAudio if you have an ice17xx-based sound card. Please be aware that the fault lies with alsa-lib not PulseAudio and will be addressed in 10.04 LTS.
- Configure PulseAudio to ignore your sound driver's misreported dB information if you experience "overdriven" sound.
- Attach a verbose PulseAudio runtime log to your PulseAudio bug report.
- Attach an ALSA codec dump to your linux bug report if jack sense (e.g., connecting headphones mutes internal laptop speakers) does not seem to function properly.
Thursday, October 1, 2009
Caveats for audio in Ubuntu Karmic Beta
In the wake of the Ubuntu Karmic Beta release, here are some audio gotchas on my radar:
* Volumes being erroneously set to 0 and/or muted upon reboot/shutdown
** We'll address this in Lucid by altering how alsactl store is called. For Ubuntu, there's arguably no need to actually call alsactl restore; PulseAudio handles volume state on its own. Granted, the approach will take some fleshing out, as we need to handle Kubuntu, Xubuntu, Ubuntu Studio, ...
* Default PulseAudio behaviour causes overdriven audio due to hardware inanity
** Thanks to some wonderful (sarcasm) hardware integration, we can work around this issue by using the patch mentioned in the comment. Please note that this patch will not be turned on for Karmic, because doing so will result in a very poor user experience for many more HDA users whose hardware are not quite so craptastic.
* Internal/External microphone selection is broken for many HDA users
** Well-known upstream, being addressed for Lucid, patches too invasive for Karmic, etc.
* Extremely high CPU usage by PulseAudio with third-party applications (Skype, I'm looking at you)
** Use the PulseAudio-aware beta of Skype
Finally, last post I described populating the alsactl init database. There are a few things of which one should be aware:
* Too quiet or too loud is usually a driver (i.e., linux) bug
** We can work around this in alsa-kernel/linux, so the first place we check is linux, not alsa-utils. In the rare case it is not a driver bug, we resort to alsactl init patches.
* You can clone the upstream alsa-utils git tree and submit patches directly
** (Next post, I'll cover how to do it.)
* Volumes being erroneously set to 0 and/or muted upon reboot/shutdown
** We'll address this in Lucid by altering how alsactl store is called. For Ubuntu, there's arguably no need to actually call alsactl restore; PulseAudio handles volume state on its own. Granted, the approach will take some fleshing out, as we need to handle Kubuntu, Xubuntu, Ubuntu Studio, ...
* Default PulseAudio behaviour causes overdriven audio due to hardware inanity
** Thanks to some wonderful (sarcasm) hardware integration, we can work around this issue by using the patch mentioned in the comment. Please note that this patch will not be turned on for Karmic, because doing so will result in a very poor user experience for many more HDA users whose hardware are not quite so craptastic.
* Internal/External microphone selection is broken for many HDA users
** Well-known upstream, being addressed for Lucid, patches too invasive for Karmic, etc.
* Extremely high CPU usage by PulseAudio with third-party applications (Skype, I'm looking at you)
** Use the PulseAudio-aware beta of Skype
Finally, last post I described populating the alsactl init database. There are a few things of which one should be aware:
* Too quiet or too loud is usually a driver (i.e., linux) bug
** We can work around this in alsa-kernel/linux, so the first place we check is linux, not alsa-utils. In the rare case it is not a driver bug, we resort to alsactl init patches.
* You can clone the upstream alsa-utils git tree and submit patches directly
** (Next post, I'll cover how to do it.)
Thursday, September 17, 2009
Limited liability, or how not to develop Karmic using Karmic
Karmic has been wonderfully jumpy these past few days. I must have some sick fascination with broken systems, as my presentation at this year's Ohio LinuxFest will focus on developing Karmic while running Karmic. Not just that, but this Saturday I'll briefly discuss Linux audio at Atlanta Linux Fest.
Now for the real meat in this post. For Karmic+1, I want Ubuntu to lead the charge in populating alsa-utils's init db.
Currently we do some pretty braindead things in alsa-utils's initscript, namely forcibly iterate over an entire set of static mixer element strings and values and attempt to set all detected audio devices to a specific state. Well, it's rather unlikely that my Logitech USB headset will have a Creative Audigy-specific "Audigy Analog/Digital Output Jack", yes?
Of course, that's just one badness, but the driving factor is to be able to conditionally set volumes on system start (for non-PulseAudio configurations) based on the machine's SSID. This approach largely resolves the "Gee, I have an Audigy X that requires the jack toggle to be muted to get audible analog output but person Y with an Audigy Z requires it to be unmuted" debacle.
So where do you come in? With current HDA codecs, using a static setting of 80% for PCM is pretty fragile. Some hardware sounds really overdriven at that setting, and others are barely audible. We need your SSID (lspci -nv|grep -A1 040[13]) and your preferred volumes! More in the following weeks.
Now for the real meat in this post. For Karmic+1, I want Ubuntu to lead the charge in populating alsa-utils's init db.
Currently we do some pretty braindead things in alsa-utils's initscript, namely forcibly iterate over an entire set of static mixer element strings and values and attempt to set all detected audio devices to a specific state. Well, it's rather unlikely that my Logitech USB headset will have a Creative Audigy-specific "Audigy Analog/Digital Output Jack", yes?
Of course, that's just one badness, but the driving factor is to be able to conditionally set volumes on system start (for non-PulseAudio configurations) based on the machine's SSID. This approach largely resolves the "Gee, I have an Audigy X that requires the jack toggle to be muted to get audible analog output but person Y with an Audigy Z requires it to be unmuted" debacle.
So where do you come in? With current HDA codecs, using a static setting of 80% for PCM is pretty fragile. Some hardware sounds really overdriven at that setting, and others are barely audible. We need your SSID (lspci -nv|grep -A1 040[13]) and your preferred volumes! More in the following weeks.
Monday, July 27, 2009
"Meanwhile, in real life"...
Firstly, I have been neglecting my Ubuntu Karmic objectives due to a sudden fit of productivity in $dayjob. I expect this lapse to be completed after the Black Hat USA briefings. (That said, if you're headed to that Sin City and have Ubuntu sound problems, find me, and we can eliminate the debugging roundtrips.)
Secondly, I am working through the powerdown issues for the remaining HDA (controllers and) codecs besides Sigmatel/IDT. The Analog Devices and Realtek ones are pains in my rear.
Lastly, some words on respect. I tend toward forcefulness - sometimes misled but mostly well-intentioned - and note that, rather than blow much hot air about the (emotional) fitness of Mono or the blatant sexism in many environments (not just FOSS), to frame the issues as obstinate juvenile mutterings reduces them to the bottom line: I (we) disrespect other people. I (we) should stop being an idiot(s). But rather than argue who needs to stop what, I am going to eradicate the tomfoolery and shenanigans that I have internalised. It's really simple: people notice when I (we) take time to help them with Ubuntu. People notice when I (we) take time to note that I (we) don't agree with sexism in presentations. For me, Ubuntu is about leading through maturity.
Secondly, I am working through the powerdown issues for the remaining HDA (controllers and) codecs besides Sigmatel/IDT. The Analog Devices and Realtek ones are pains in my rear.
Lastly, some words on respect. I tend toward forcefulness - sometimes misled but mostly well-intentioned - and note that, rather than blow much hot air about the (emotional) fitness of Mono or the blatant sexism in many environments (not just FOSS), to frame the issues as obstinate juvenile mutterings reduces them to the bottom line: I (we) disrespect other people. I (we) should stop being an idiot(s). But rather than argue who needs to stop what, I am going to eradicate the tomfoolery and shenanigans that I have internalised. It's really simple: people notice when I (we) take time to help them with Ubuntu. People notice when I (we) take time to note that I (we) don't agree with sexism in presentations. For me, Ubuntu is about leading through maturity.
Subscribe to:
Posts (Atom)