Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
2010-09-01 20:06, pl bossart skrev:
Probably either one will work, but if we're about to release 0.9.22
(heard something from Lennart yet?), I suggest we go with my version for
0.9.22 as that one is the least invasive (only touches non-tsched
devices), and keep Pierre's version in master.
Sounds reasonable. Pierre, what's your take?
That would mean an additional post-release patch for tsched devices. I
am lazy and would prefer a one-stop fix. I don't care if this is
David's or mine, as long as the solution works for both cases.
The only real difference is the bytes/ms parameter. Although ms are
more intuitive, the bytes makes more sense from a hardware point of
view. If you pass a parameter in ms, there might be cases where the
actual number of bytes is lower than the DMA burst, it'll depend on
what frequency the sink operates at. There are some cases where
alsa-sink works at 8kHz (BT-SCO) or 48kHz (all other cases), a 6x
variability in the rewind behavior is difficult to handle.
Fair enough, how about the attached compromise (untested)? If you then
would like to turn the define of dma_rewind_margin_bytes into a
parameter, that should be fairly simple.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 5ae6c880e20adfa0f372f2caf293e70253651c5a Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Thu, 2 Sep 2010 08:22:36 +0200
Subject: [PATCH] ALSA: Fix calculation of rewind margins
For non-tsched devices, use 20 ms as a default rewind margin.
Also make sure that we have at least 256 bytes as rewind margin for
all devices, to avoid problems with DMA controllers.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/modules/alsa/alsa-sink.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index a253cc5..097bb20 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -63,6 +63,9 @@
#define DEFAULT_DEVICE default
+#define NON_TSCHED_REWIND_MARGIN_USEC (20*PA_USEC_PER_MSEC)/* 20ms -- Default rewind margin for non-tsched devices */
+#define DMA_REWIND_MARGIN_BYTES (256) /* Make sure we're always have a rewind margin of at least 256 bytes - to avoid problems with some DMA controllers */
+
#define DEFAULT_TSCHED_BUFFER_USEC (2*PA_USEC_PER_SEC) /* 2s-- Overall buffer size */
#define DEFAULT_TSCHED_WATERMARK_USEC (20*PA_USEC_PER_MSEC)/* 20ms -- Fill up when only this much is left in the buffer */
@@ -1309,7 +1312,15 @@ static int process_rewind(struct userdata *u) {
return -1;
}
-unused_nbytes = u-tsched_watermark + (size_t) unused * u-frame_size;
+
+if (u-use_tsched)
+unused_nbytes = u-tsched_watermark;
+else
+unused_nbytes = pa_usec_to_bytes(NON_TSCHED_REWIND_MARGIN_USEC, u-sink-sample_spec);
+if (unused_nbytes DMA_REWIND_MARGIN_BYTES)
+unused_nbytes = DMA_REWIND_MARGIN_BYTES;
+
+unused_nbytes += (size_t) unused * u-frame_size;
if (u-hwbuf_size unused_nbytes)
limit_nbytes = u-hwbuf_size - unused_nbytes;
--
1.7.0.4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Keeping a USB mic selected when unplugged plugged in again
'Twas brillig, and Whit Blauvelt at 02/09/10 05:21 did gyre and gimble: Hi, This is on an Ubuntu 10.4 system, with an internal sound card I don't use at all, and a USB headset with mic that isn't always plugged in. The goal is, when it's freshly plugged in, to have it work without extra steps. I have that working for the earphones, but not the mic. To get it the USB headset listed as card-0 rather than card-1 I created a file /etc/modutils/sound_cards with the following: alias snd-card-0 snd-usb-audio alias snd-card-1 snd-via82xx-modem That worked, for whatever it's worth. Then in System Preferences PulseAudio Preference (which I think came into the system from something extra I installed while mucking with this) I went to Simultaneous Output and enabled that. Then in System Preferences Sound Output I selected Simultaneous output to ... which unlike selecting the single output device as the USB headset, persists when the headset is unplugged and so works right away when it's plugged back in. In System Preference Hardware I disabled the internal card (for what that's worth). Here's the problem I haven't solved. In System Preferences Sound Input the listing for the USB device comes back soon after it's plugged in again. And it's the only listing there. But the thing's not checked! My .pulse directory has a file, [long-number]-default-source which gains and loses the USB device's name as it's plugged and unplugged, but that file stays the same whether it's checked or not. I can't find where the checked/unchecked status is stored, or how to hard-code it so the microphone always is selected just as soon as the headset is plugged in. This is not good when trying to answer a Skype call. Is there some way to make the microphone default to on? There isn't really a smooth way to do this with the current code sadly. I've written about this before and have a proposal to solve it, but I've not started work on it yet due to it not being fully approved as an approach yet. http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Two identical USB sound-cards - second card fails to load because card-name found in hashmap.
'Twas brillig, and Ivar Mossin at 01/09/10 23:23 did gyre and gimble: On Mon, Aug 30, 2010 at 5:49 PM, Tanu Kaskinen ta...@iki.fi mailto:ta...@iki.fi wrote: I pushed a new patch to my repo. The patch should now solve the problem of identically named sinks and sources too. Please test :) I pulled your latest changes and compiled. According to the logs both cards with sinks and sources loaded perfectly. Thank you very much for your effort. :) OK, I've pushed Tanu's patch to master now. Thanks for testing. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ 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
'Twas brillig, and David Henningsson at 02/09/10 07:29 did gyre and gimble: 2010-09-01 20:06, pl bossart skrev: Probably either one will work, but if we're about to release 0.9.22 (heard something from Lennart yet?), I suggest we go with my version for 0.9.22 as that one is the least invasive (only touches non-tsched devices), and keep Pierre's version in master. Sounds reasonable. Pierre, what's your take? That would mean an additional post-release patch for tsched devices. I am lazy and would prefer a one-stop fix. I don't care if this is David's or mine, as long as the solution works for both cases. The only real difference is the bytes/ms parameter. Although ms are more intuitive, the bytes makes more sense from a hardware point of view. If you pass a parameter in ms, there might be cases where the actual number of bytes is lower than the DMA burst, it'll depend on what frequency the sink operates at. There are some cases where alsa-sink works at 8kHz (BT-SCO) or 48kHz (all other cases), a 6x variability in the rewind behavior is difficult to handle. Fair enough, how about the attached compromise (untested)? If you then would like to turn the define of dma_rewind_margin_bytes into a parameter, that should be fairly simple. That patch works fine too with the chordtest test. In order to do more testing however, I also tried the following two cherry picks to stable-queue _instead_ of your patch: commit d11cd33e3aff14fdd66826b3252d90b1b0e38c48 Author: Lennart Poettering lenn...@poettering.net Date: Tue Feb 23 03:23:22 2010 +0100 alsa: don't make use of tsched related variables when tsched is disabled commit 4df443bbe682055a41e7c2248877dcc7682a69b8 Author: Pierre-Louis Bossart pierre-louis.boss...@intel.com Date: Thu Apr 29 10:48:11 2010 -0500 add rewind-safeguard parameter Rewinding the ring buffer completely causes audible issues with DMAs. Previous solution didn't work with tsched=0, and used tsched_watermark for guardband, which isn't linked to hardware and could become really high if underflows occurred. Added separate parameter that can be tuned to hardware limitations and size of DMA bursts. This approach also fixed the chordtest test case. Obviously to fix that test case, I'd rather cherry-pick those two patches than introduce a new patch only on stable-queue. David, as it's obvious that I'm not fully up-to-speed with how this alsa stuff works in any great depth, what do you think your patch adds on top of the above two? My primary concern is that with the current git master version, the u-tsched_watermark is not used at all to calculate unused_nbytes, whereas in your patch it is (the usage of u-tsched_watermark was removed in git master in Pierre's patch above). Now I can see that the general aim in Peirre's change was to prevent rewinding too far, but with your patch it seems to stop it rewinding too little (have I interpreted this right?) and there is no upper limit on the amount rewound (in tsched mode with a massive watermark at least). So is there still something missing in your patch? Can the rewind now be too much for the DMA controller (a problem alluded to in the comments in Pierre's fix). Right, I hope I've asked the right questions here. I'm aware that my not groking things fully isn't helping but I'm also keen to not cock things up :D In order to keep things sensible and prevent divergence, I think it's wise to cherry pick the above two patches to stable-queue and make any further change needed on top of that. This way the patch should apply to git master and stable-queue and I can prevent patch divergence and thus the strange reoccurances of problems post 0.9.22 when we ultimately release git master under whatever version it turns out to be. I think that makes sense. WDYT? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Keeping a USB mic selected when unplugged plugged in again
On Thu, Sep 02, 2010 at 08:45:18AM +0100, Colin Guthrie wrote: I can't find where the checked/unchecked status is stored, or how to hard-code it so the microphone always is selected just as soon as the headset is plugged in. This is not good when trying to answer a Skype call. Is there some way to make the microphone default to on? There isn't really a smooth way to do this with the current code sadly. ... http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ Wow. That's an impressively thorough analysis and proposal. Glad you're working on it. For my specific case, is a kludgey fix possible? Instead of having to mouse through System Preferences Sound Input to check what at this point is the only radio button there, is a command-line script possible that would send the same signal as checking that button? I've always got open terminal sessions, so could far more quickly type restoremic or something than do all that mousing. If I knew what that script should do, I could also just have it run from cron every minute - have it check if the mic is plugged in since that shows in .pulse/-default-source, and if it is plugged in force it to be actually selected. Or even better, there might be a way to piggyback on whatever is noticing the mic's been plugged in, and have it then turn it on by running the auxilliary script by default. Obviously this would be a kludge, not a universal solution. But I'd be happy. A major design advantage of *nix is that close to 100% of it can be configured and run with text files and terminal commands. If sound is moving away from that, becoming dependent on a GUI interface with commands that can't be done except through a GUI, that's unfortunate. GUI's are great when they work, but for anything complex the traditional edit files, run commands *nix approach allows more thorough and fine-grained control. So, is there a command-line way to do what checking that radio button accomplishes? Thanks, WHit ___ 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
2010-09-02 10:41, Colin Guthrie skrev: 'Twas brillig, and David Henningsson at 02/09/10 07:29 did gyre and gimble: 2010-09-01 20:06, pl bossart skrev: Probably either one will work, but if we're about to release 0.9.22 (heard something from Lennart yet?), I suggest we go with my version for 0.9.22 as that one is the least invasive (only touches non-tsched devices), and keep Pierre's version in master. Sounds reasonable. Pierre, what's your take? That would mean an additional post-release patch for tsched devices. I am lazy and would prefer a one-stop fix. I don't care if this is David's or mine, as long as the solution works for both cases. The only real difference is the bytes/ms parameter. Although ms are more intuitive, the bytes makes more sense from a hardware point of view. If you pass a parameter in ms, there might be cases where the actual number of bytes is lower than the DMA burst, it'll depend on what frequency the sink operates at. There are some cases where alsa-sink works at 8kHz (BT-SCO) or 48kHz (all other cases), a 6x variability in the rewind behavior is difficult to handle. Fair enough, how about the attached compromise (untested)? If you then would like to turn the define of dma_rewind_margin_bytes into a parameter, that should be fairly simple. That patch works fine too with the chordtest test. In order to do more testing however, I also tried the following two cherry picks to stable-queue _instead_ of your patch: commit d11cd33e3aff14fdd66826b3252d90b1b0e38c48 Author: Lennart Poettering lenn...@poettering.net Date: Tue Feb 23 03:23:22 2010 +0100 alsa: don't make use of tsched related variables when tsched is disabled commit 4df443bbe682055a41e7c2248877dcc7682a69b8 Author: Pierre-Louis Bossart pierre-louis.boss...@intel.com Date: Thu Apr 29 10:48:11 2010 -0500 add rewind-safeguard parameter Rewinding the ring buffer completely causes audible issues with DMAs. Previous solution didn't work with tsched=0, and used tsched_watermark for guardband, which isn't linked to hardware and could become really high if underflows occurred. Added separate parameter that can be tuned to hardware limitations and size of DMA bursts. This approach also fixed the chordtest test case. Obviously to fix that test case, I'd rather cherry-pick those two patches than introduce a new patch only on stable-queue. David, as it's obvious that I'm not fully up-to-speed with how this alsa stuff works in any great depth, what do you think your patch adds on top of the above two? So my only worry, but I might be wrong, is that a fixed limit of 256 bytes in combination with high sample rates (think 8 channels, 192 kHz, 32 bit float, that will make 256 bytes 0,04 ms only), will not be enough. We'll rewind back and before we have time to fill it up again we will get an underrun (and possibly DMA failure?). So that's why I want to see a ms based margin as well as a byte-based one. For tsched devices, the watermark is a dynamic ms-based margin that seems to have been working well (AFAIK), but for non-tsched devices, we have had no margin at all, causing failure. As a summary, Pierre is afraid a ms-based one will rewind too far if the sample rate is low, and I'm afraid a byte-based one will rewind too far if the sample rate is high. My primary concern is that with the current git master version, the u-tsched_watermark is not used at all to calculate unused_nbytes, whereas in your patch it is (the usage of u-tsched_watermark was removed in git master in Pierre's patch above). Now I can see that the general aim in Peirre's change was to prevent rewinding too far, but with your patch it seems to stop it rewinding too little (have I interpreted this right?) and there is no upper limit on the amount rewound (in tsched mode with a massive watermark at least). Both patches aim not to rewind too far, if my one isn't, something is fundamentally wrong with my version. So is there still something missing in your patch? Can the rewind now be too much for the DMA controller (a problem alluded to in the comments in Pierre's fix). Right, I hope I've asked the right questions here. I'm aware that my not groking things fully isn't helping but I'm also keen to not cock things up :D In order to keep things sensible and prevent divergence, I think it's wise to cherry pick the above two patches to stable-queue and make any further change needed on top of that. This way the patch should apply to git master and stable-queue and I can prevent patch divergence and thus the strange reoccurances of problems post 0.9.22 when we ultimately release git master under whatever version it turns out to be. I think that makes sense. WDYT? 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
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
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. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
