Pulseaudio-discuss

Popular Threads From Pulseaudio-discuss:

{PATCH] AC3 passthrough support

Changing default soundcard on attach/detach of soundcards

Does pulseaudio require alsa/oss

Multiple users (kde) on Debian

Disabling ALSA period interrupts

List Statistics

Total Threads: 273
Total Posts: 1068

Phrases Used to Find This Thread

Page 1 of 1

30-04-2010 12:24 PM

Pulseaudio-discuss member admin is online now

User

30-04-2010 02:44 PM

Pulseaudio-discuss member admin is online now

User

30-04-2010 05:44 PM

Pulseaudio-discuss member admin is online now

User

30-04-2010 06:39 PM

Pulseaudio-discuss member admin is online now

User

08-05-2010 12:25 AM

Pulseaudio-discuss member admin is online now

User

08-05-2010 04:12 AM

Pulseaudio-discuss member admin is online now

User

12-05-2010 08:22 AM

Pulseaudio-discuss member admin is online now

User

12-05-2010 01:42 PM

Pulseaudio-discuss member admin is online now

User

12-05-2010 02:00 PM

Pulseaudio-discuss member admin is online now

User

#10

12-05-2010 02:08 PM

Pulseaudio-discuss member admin is online now

User

#11

12-05-2010 02:50 PM

Pulseaudio-discuss member admin is online now

User

#12

12-05-2010 03:15 PM

Pulseaudio-discuss member admin is online now

User

#13

12-05-2010 03:16 PM

Pulseaudio-discuss member admin is online now

User

pl bossart wrote:
> When PulseAudio is used and all PCM is routed through PulseAudio
> (Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
> So why not disable them entirely to reduce the number of wakeups? ...
> There are probably some cases where you don't want this type of
> behavior (broken hardware, legacy code with multiple-buffering,
> disabled timer in PulseAudio),

It's interesting that all ALSA applications except PA are "legacy". :)

> so I think it would make sense to request the disabling of interrupts
> when hw_params are set, since this is also the time when period sizes
> are set.

Yes. For compatibility with the existing ALSA API, this needs to be
a flag that is not enabled by default.

> I am aware that some changes would be needed in pcm_lib.c, where all
> the error checks are done.

Plus all the API changes in the ALSA kernel framework, the ALSA kernel/
userspace interface, and the alsa-lib interface.

I'll see if I can get this done over the weekend ...

Regards,
Clemens
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi Clemens,

>> When PulseAudio is used and all PCM is routed through PulseAudio
>> (Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
>> So why not disable them entirely to reduce the number of wakeups? ...
>> There are probably some cases where you don't want this type of
>> behavior (broken hardware, legacy code with multiple-buffering,
>> disabled timer in PulseAudio),
>
> It's interesting that all ALSA applications except PA are "legacy". �:)

Ha. Nice slip. I didn't mean legacy was bad... It's perfectly ok to
use multiple buffers and interrupts in a variety of apps.

>> so I think it would make sense to request the disabling of interrupts
>> when hw_params are set, since this is also the time when period sizes
>> are set.
>
> Yes. �For compatibility with the existing ALSA API, this needs to be
> a flag that is not enabled by default.

Agreed. This shouldn't even be mandatory since this option might not
be possible in all platforms.

>> I am aware that some changes would be needed in pcm_lib.c, where all
>> the error checks are done.
>
> Plus all the API changes in the ALSA kernel framework, the ALSA kernel/
> userspace interface, and the alsa-lib interface.

I am not following this point. If you add a simple flag to an existing
interface, why would we need to change the kernel/userspace inferface?
This change should be possible in a backwards compatible manner as an
additional option provided to the application developer.
Cheers
-Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 2010-04-29 at 17:38 -0500, pl bossart wrote:
> Howdy,
> When PulseAudio is used and all PCM is routed through PulseAudio
> (Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
> PulseAudio uses a timer to refill buffers and the period interrupts
> are not used at all.
>
> So why not disable them entirely to reduce the number of wakeups? This
> is possible with a number of existing DMA controllers. The simple
> patch attached shows a proof-of-concept on HDAudio, it's been working
> for 5 hours on my Fedora12 laptop without any glitches and powertop
> does show _zero_ wakeups from the HDAudio controller (except on
> startup). I am told by my colleagues working in Windows environments
> that this is what's done on Vista/Windows7 btw. This isn't to say
> Windows is great but that artificial generation of not-needed
> interrupts is avoidable.
>
> There are probably some cases where you don't want this type of
> behavior (broken hardware, legacy code with multiple-buffering,
> disabled timer in PulseAudio), so I think it would make sense to
> request the disabling of interrupts when hw_params are set, since this
> is also the time when period sizes are set. I am aware that some
> changes would be needed in pcm_lib.c, where all the error checks are
> done. Takashi, Jaroslav, Lennart, what do you think?
> Feedback and suggestions welcome.
> Cheers
> - Pierre

How do you handle any clock drift here between the HDA hardware
interface clock and the PA timer ?

Liam

--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Hi Liam,

> How do you handle any clock drift here between the HDA hardware
> interface clock and the PA timer ?

Good question. This is already handled by PulseAudio. The timer isn't
programmed with a fixed value but is adapted precisely to track
differences between system time and audio time. PulseAudio relies on
snd_pcm_avail() to query the number of samples played, and correlates
timer values with samples. There's a longer blurb on this at [1]. The
use of timers has pretty much broken most of the drivers as the values
returned by snd_pcm_avail weren't precise enough. However it's been a
year and a half now and things are ok on most hardware. The main
reason why this is interesting is that you can vary the latency on the
fly simply by reprogramming the timer. Having to define a fixed period
size for all use cases is a real problem for us. You end-up with a
compromise between latency and power that makes things suboptimal
across the board.
Cheers
-Pierre

[1] http://0pointer.de/blog/projects/pulse-glitch-free.html
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Thu, 29.04.10 17:38, pl bossart () wrote:

> Howdy,
> When PulseAudio is used and all PCM is routed through PulseAudio
> (Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
> PulseAudio uses a timer to refill buffers and the period interrupts
> are not used at all.

This patch looks very interesting and desirable. This is something have
long been waiting for.

I wonder how this actually relates to
snd_pcm_sw_params_set_period_event() though.

> So why not disable them entirely to reduce the number of wakeups? This
> is possible with a number of existing DMA controllers. The simple
> patch attached shows a proof-of-concept on HDAudio, it's been working
> for 5 hours on my Fedora12 laptop without any glitches and powertop
> does show _zero_ wakeups from the HDAudio controller (except on
> startup). I am told by my colleagues working in Windows environments
> that this is what's done on Vista/Windows7 btw. This isn't to say
> Windows is great but that artificial generation of not-needed
> interrupts is avoidable.
>
> There are probably some cases where you don't want this type of
> behavior (broken hardware, legacy code with multiple-buffering,
> disabled timer in PulseAudio), so I think it would make sense to
> request the disabling of interrupts when hw_params are set, since this
> is also the time when period sizes are set. I am aware that some
> changes would be needed in pcm_lib.c, where all the error checks are
> done. Takashi, Jaroslav, Lennart, what do you think?

I am sold!

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > This patch looks very interesting and desirable. This is something have
> long been waiting for.
>
> I wonder how this actually relates to
> snd_pcm_sw_params_set_period_event() though.

snd_pcm_sw_params_set_period_event() defines whether or not you will
have poll wakeups when a period elapses. But if you decide not to have
poll wakeups, you still end-up with interrupts that were generated for
no good reason. You might think that this could be extended to disable
interrupts as well, but this would be hard since this can only be done
when the DMA linked list is created, ie when the hw_params are set.
Plus the sw_params may be changed on-the-fly, which isn't the case for
hw_params/interrupts. We would really need a flag used with
snd_pcm_open or when hw_params are set.

>> Takashi, Jaroslav, Lennart, what do you think?
> I am sold!
Good to hear.
Cheers
-Pierre
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. >
>> Howdy,
>> When PulseAudio is used and all PCM is routed through PulseAudio
>> (Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
>> PulseAudio uses a timer to refill buffers and the period interrupts
>> are not used at all.
>
> This patch looks very interesting and desirable. This is something have
> long been waiting for.
>
> I wonder how this actually relates to
> snd_pcm_sw_params_set_period_event() though.
>
>> So why not disable them entirely to reduce the number of wakeups? This
>> is possible with a number of existing DMA controllers. The simple
>> patch attached shows a proof-of-concept on HDAudio, it's been working
>> for 5 hours on my Fedora12 laptop without any glitches and powertop
>> does show _zero_ wakeups from the HDAudio controller (except on
>> startup). I am told by my colleagues working in Windows environments
>> that this is what's done on Vista/Windows7 btw. This isn't to say
>> Windows is great but that artificial generation of not-needed
>> interrupts is avoidable.
>>
>> There are probably some cases where you don't want this type of
>> behavior (broken hardware, legacy code with multiple-buffering,
>> disabled timer in PulseAudio), so I think it would make sense to
>> request the disabling of interrupts when hw_params are set, since this
>> is also the time when period sizes are set. I am aware that some
>> changes would be needed in pcm_lib.c, where all the error checks are
>> done. Takashi, Jaroslav, Lennart, what do you think?
>
> I am sold!
>
> Lennart
>

Some care would need to be taken with regards to detecting xruns.
I think the alsa code currently uses the interrupt callback to detect this.
I have seen a Windows 7 machine happily loop the audio buffer
uncontrollably, so I assume it has problems detecting xruns as well.
Some sound card hardware only updates the hw pointer at around dma
interrupt event time, so again using the interrupt is used to improve
the accuracy of the hw pointer with interpolation used between
interrupts.
Some sound card hardware has very small hardware buffers, so PA will
have to be waking up as often as the dma interrupts in order to keep
the audio hardware buffers full enough.
In how many cased would PA have to wake up less often than the DMA interrupt?
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > Some care would need to be taken with regards to detecting xruns.
> I think the alsa code currently uses the interrupt callback to detect this.
> I have seen a Windows 7 machine happily loop the audio buffer
> uncontrollably, so I assume it has problems detecting xruns as well.

When the PulseAudio timer fires, the use of snd_pcm_avail() will force
a call to .pointer and will detect underflows. PulseAudio modilfies
its watermark when underflows occur so that more time is allocated to
refilling the ring buffer.
There are probably some cases I didn't plan for, but on paper I don't
really see a show-stopper here.

> Some sound card hardware only updates the hw pointer at around dma
> interrupt event time, so again using the interrupt is used to improve
> the accuracy of the hw pointer with interpolation used between
> interrupts.

If the hardware doesn't provide an accurate hw pointer, then the
timer-based scheduling should not be used I agree.

> Some sound card hardware has very small hardware buffers, so PA will
> have to be waking up as often as the dma interrupts in order to keep
> the audio hardware buffers full enough.
> In how many cased would PA have to wake up less often than the DMA interrupt?

This patch is mainly for music playback where you have more than 2s
buffered in the ring buffer. PulseAudio will wake-up after 1.9s or so,
as the ring buffer becomes empty, and when it does the wake-up may be
grouped with other system events with the timer slack. Having one or
more interrupts in the middle or the ring buffer will reduce the
efficiency of sleep modes that are being introduced with Moorestown
and future Atom-based SOCs.
So again this patch isn't for everyone. All standard disclaimers
apply, if you have a pre-existing conditon tell your doctor etc. If
there's a 4K ring buffer, this is not useful. If your hardware is
broken, stay the course with the current solution. If PulseAudio is
disabled in your distro, this is of no interest to you. In all these
cases, this patch doesn't change anything, the behavior is the same.
But if you want to optimize for power and latency isn't a concern,
then these interrupts can be disabled and need to.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Tue, 11 May 2010, pl bossart wrote:

> Here's a proposal for an alsa-lib modification to allow applications
> to disable interrupts (if the hardware can do so).

Please, use tabs for block indention for alsa-lib.

> I used the flag field in hw_params, this looked like a good candidate
> to convey this information needed by the driver. I don't really like
> adding two new routines, but I don't think there's any other way.
> Still 2 points to be worked out:
> - I couldn't figure out how to make these two new symbols known to
> PulseAudio. Somehow there's a missing symbol that prevents PA modules
> from loading, not sure where it needs to be declare

Are you sure that you're using new libraries? 'ldd' and 'nm' tools will
help you to determine what's wrong with symbols.

> - I thought I could make use of the same flag on the driver side, but
> the code in pcm_native.c makes a peculiar use of hw_params->flag. It
> looks like this field is used as an internal variable.
>
> for (k = 0; k < constrs->rules_num; k++) {
> struct snd_pcm_hw_rule *r = &constrs->rules[k];
> unsigned int d;
> int doit = 0;
> if (r->cond && !(r->cond & params->flags))
> continue;

Ignore this. I don't know about any place where r->cond is used (!= 0) in
the current ALSA driver, so eating one more bit from params->flags is OK.
Just put the kernel asound.h in sync with library asound.h.

Jaroslav

-----
Jaroslav Kysela <>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Fri, Apr 30, 2010 at 7:38 AM, pl bossart <> wrote:
> Howdy,
> When PulseAudio is used and all PCM is routed through PulseAudio
> (Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
> PulseAudio uses a timer to refill buffers and the period interrupts
> are not used at all.

It seems the requirement is just to have as least wakeups as possible
in order to
maximize power savings.
If so, then how about setting the period size slightly smaller than
the ring-buffer: the
difference being just enough to refill the ring buffer. Of course, you
would have to
enforce full-buffer-size as the start threshold.
We do just that to implement low-power-audio-mode for latest Samsung
SoC's I2S blocks.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. > It seems the requirement is just to have as least wakeups as possible
> in order to
> maximize power savings.
> If so, then how about setting the period size slightly smaller than
> the ring-buffer: the
> difference being just enough to refill the ring buffer. Of course, you
> would have to
> enforce full-buffer-size as the start threshold.
> We do just that to implement low-power-audio-mode for latest Samsung
> SoC's I2S blocks.

Thanks for the heads-up Jassi, this is interesting info that does show
the need to reduce the number of wakeups in embedded low-power
solutions...
This might be almost equivalent to the timer approach in terms of # of
wakeups, however the timer can be reprogrammed on-the-fly whereas
periods can only be changed by closing and reopening the device. You
can also adjust the timer shall underflows occur. And the timer slack
lets the kernel group events. Not to mention that you will need
specific apps written to make use of this mode. The only drawback of
the timer approach is that you need to keep track of drifts between
system and audio clock and that you need the hardware and driver to
report the hw_ptr with precision.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Wed, May 12, 2010 at 10:50 PM, pl bossart <> wrote:
>> It seems the requirement is just to have as least wakeups as possible
>> in order to
>> maximize power savings.
>> If so, then how about setting the period size slightly smaller than
>> the ring-buffer: the
>> difference being just enough to refill the ring buffer. Of course, you
>> would have to
>> enforce full-buffer-size as the start threshold.
>> We do just that to implement low-power-audio-mode for latest Samsung
>> SoC's I2S blocks.
>
> Thanks for the heads-up Jassi, this is interesting info that does show
> the need to reduce the number of wakeups in embedded low-power
> solutions...
> This might be almost equivalent to the timer approach in terms of # of
> wakeups, however the timer can be reprogrammed on-the-fly whereas
> periods can only be changed by closing and reopening the device. You
> can also adjust the timer shall underflows occur. And the timer slack
> lets the kernel group events. Not to mention that you will need
> specific apps written to make use of this mode. The only drawback of
> the timer approach is that you need to keep track of drifts between
> system and audio clock and that you need the hardware and driver to
> report the hw_ptr with precision.
.... another negative is having to hack the alsa stack.
I couldn't use the timer thing because the system has to be woken up
from suspend(and I2S intr is one of the wakeup sources) and maybe
for moorstown/atom also you'd go to sleep/suspend? make sure if the
timer based approach could work there.
Also, at least for embedded systems, such audio mode switching is done
at a level coarse enough(the user sets the 'Hold' switch) that overall power
savings(unloading unnecessary driver modules upon first LPAM suspend
and reloading only after the last) is much more than a minor click in playback
due to close->open of the audio stream.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. On Wed, May 12, 2010 at 08:50:42AM -0500, pl bossart wrote:

> This might be almost equivalent to the timer approach in terms of # of
> wakeups, however the timer can be reprogrammed on-the-fly whereas
> periods can only be changed by closing and reopening the device. You
> can also adjust the timer shall underflows occur. And the timer slack
> lets the kernel group events. Not to mention that you will need

The timer is also useful for allowing PulseAudio to dynamically adjust
the period size as the runtime situation changes - if you're running
high latency streams and have a low latency application start up then
PulseAudio can just change the timer to get more frequent events.
_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

#14

12-05-2010 06:10 PM

Pulseaudio-discuss member admin is online now

User

#15

12-05-2010 07:15 PM

Pulseaudio-discuss member admin is online now

User

#16

13-05-2010 04:56 AM

Pulseaudio-discuss member admin is online now

User

#17

14-05-2010 05:07 AM

Pulseaudio-discuss member admin is online now

User

#18

14-05-2010 05:39 AM

Pulseaudio-discuss member admin is online now

User

#19

14-05-2010 06:27 AM

Pulseaudio-discuss member admin is online now

User

#20

14-05-2010 09:12 AM

Pulseaudio-discuss member admin is online now

User

Page 1 of 1

NewsArc Lists | Culture Pages | Computing Archive | Media-Pages

Link to this page on your blog or website by copying the HTML code below and pasting it into your site:

Next Thread »