Re: [pulseaudio-discuss] How to save mixer settings?
Dear Jan, Am Montag, den 06.09.2010, 09:51 +0200 schrieb Jan Kasprzak: On my laptop the Front mic input is routed to the speakers/headphones after boot, causing unnecessary noise and sometimes even a feedback loop. I can mute it using amixer -D hw:0 set 'Front mic' mute, but it becomes unmuted every time I suspend and resume the laptop, or every time I log in. Is it possible to save the mixer settings w/ pulse? I am sorry, I cannot answer your question. But I guess PA is not responsible for that and this should be ALSA’s responsibility. My laptop is ASUS F3e with intel HDA sound with Realtek ALC660-VD codec chip (snd-hda-intel module is loaded with model=lenovo switch because of an unrelated problem described here: http://www.fi.muni.cz/~kas/blog/index.cgi/computers/intel-hda-headphone-speakers.html ). 1. Did you report that issue to the alsa-devel list [1][2]? 2. Your issue is from September 2008. What ALSA version did you use back then and what version do you use now? 3. Have you tried more recent ALSA versions? I think a lot of fixes have been made. 4. Since you have an ASUS system there might be a better value for `model`? 5. If nothing helps and the problem is still present, maybe HDA-Analyzer [3] can help you to fix it correctly. Thanks, Paul [1] http://mailman.alsa-project.org/mailman/listinfo/alsa-devel [2] http://alsa-project.org/main/index.php/Help_To_Debug [3] http://alsa-project.org/main/index.php/Help_To_Debug_Intel_HDA signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to save mixer settings?
On Mon, Sep 6, 2010 at 2:51 AM, Jan Kasprzak k...@fi.muni.cz wrote: Hello, world!\n On my laptop the Front mic input is routed to the speakers/headphones after boot, causing unnecessary noise and sometimes even a feedback loop. I can mute it using amixer -D hw:0 set 'Front mic' mute, but it becomes unmuted every time I suspend and resume the laptop, or every time I log in. Is it possible to save the mixer settings w/ pulse? It's odd that the default for your mic would be routed to your speakers so you might need to figure out the root problem. A workaround may be to try muting it in Pulse instead which should be persistent. If that doesn't work then after you use amixer try running alsactl store and see if it keeps the settings. Richard ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
On 2010-09-04 14:10, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 03/09/10 09:46 did gyre and gimble: 2010-09-02 16:06, pl bossart skrev: Agreed: You can pick those two patches, and then we add a third patch to both branches, which brings back the watermark for tsched devices and 20 ms for non-tsched. Assuming my suspicion is not disproved, of course. What does Pierre think of that? I don't want the watermark to be used for rewinds. The watermark is there for timer-based scheduling, so that you have enough time to wake-up from sleep and still refill the buffer. The rewinds happens when the processor is already awake, pulseaudio up and running and only the remix part needs to happen. Plus the watermark varies and the logic could really be improved. Also I think 20ms for rewinds is way too much. This will kill your actual latency. Imagine you have a low-latency app that starts, the first sample would be heard after at best 20ms. Not acceptable for speech or interactive sounds. But I agree that 256-bytes isn't fool-proof for heavy duty use cases such 8ch 192kHz 32-bit float. So how about we keep 256 bytes (1.33 ms for 48kHz) but add a 1.33 ms threshold to make sure we never rewind below. rewind_safeguard = max(256, pa_usec_to_bytes(1330)); This way you solve both the hardware issue (frequency independent) and leave enough headroom for the system to avoid underflows. Whether 1,33 ms or 20 ms is best - I assume your guess is as good as mine. Colin, feel free to go ahead with Pierre's suggestion - it's likely to be good enough. As for the watermark usage, I admit to not knowing enough of CPU scheduling and wake-up times to either prove Pierre right or wrong. OK, I've done this now. The patch is attached. It's based on stable-queue with the two previous patches cherry-picked first (and also Tanu's 0525807b63c11d3d71526cec553e8d80ad3f09cd which fixed a complier warning, but shouldn't get in the way) However, in testing this I had some problems. Likely this is due to me testing hard/more thoroughly than before. I found that using the attached patch fixed the chordtest.sh case for tsched=0, however, when running pavucontrol at the same time, everything started to go wrong pretty quickly (after two or three streams). When things when wrong, they generally stayed wrong. i.e. ctrl+c on the chordtest.sh kills all the streams, but if I rerun it, then the very first stream is generally cocked up. Interestingly a paplay seemed to work fine. So I changed the 1330 usec to 2 and tried again. This had slightly better results, but still broke the chordtest.sh case after three streams (fairly repeatable) when pavucontrol is running (unsurprisingly it also worked fine when pavucontrol was not running). The difference in this case however was the rerunning the test after an initial failure worked fine. The sound was back to normal on the first stream and only generally cocked up when it hit the third stream. I'm just guessing here, but I'm not sure you're experiencing the same problem then. It could be that you're having underruns from too high CPU usage instead, or something. And with tsched=0, we can't compensate by increasing the watermark. So what does this test mean? pavucontrol obviously affects the latency of the sink due to it's VI meters. This obviously increases the likelihood of a rewind being triggered.So, with this in mind what values do you suggest we pick? Pierre, is it your understanding that it is when DMA transfer collides with cpu-RAM transfer that makes the DMA stream to become broken permanently? Or exactly what is it that makes it break? I'd be interested as to whether anyone else can repeat this experiment and get similar results. Unfortunately I haven't got around to test it yet :-( -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
So what does this test mean? pavucontrol obviously affects the latency of the sink due to it's VI meters. This obviously increases the likelihood of a rewind being triggered.So, with this in mind what values do you suggest we pick? Pierre, is it your understanding that it is when DMA transfer collides with cpu-RAM transfer that makes the DMA stream to become broken permanently? Or exactly what is it that makes it break? The low-latency setting has nothing to do with rewinds. It's when you actually change the volume that you will rewind and remix with the new stream volume. You could set a super low latency and rewind exactly once when the stream starts. There are two issues with the rewind. One is a race condition between the DMA and the ring buffer update. If you rewind and update the ring buffer, the DMA may actually have already fetched older data. The second is that you could experience underflows if you don't do the update fast enough. By enabling logs you should be able to find out if there are real underflows. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
