Re: smix plugin available?

Re: smix plugin available?

[Jaroslav Kysela]

On Wed, 27 Nov 2002, Paul Davis wrote:

> >This is my personal preference. In this model the only service ALSA has to
> >supply are:
> >
> >1. initial configuration/start/stop.
> >2. mmapable DMA buffer
> >3. fact and precise ioctl telling the current HW pointer in the buffer. If the
> >card is not queried each time, then the "last period interrupt" timestamp
> >should be included.
> 
> ALSA supplies all 3 of these. You can use them by themselves without
> the rest of the API if you want. The only problem arises with hardware
> that cannot give you accurate h/w pointer positions.
> 
> >Please stop the complication of "available/delay" etc. Just the raw
> >pointer.  Each application knows where its application pointer is, so
> >it can easily calculate delay/available and decide for itself whether
> >there was an overrun or not.
> 
> actually, it can't. if the user space application is delayed for
> precisely 1 buffer's worth of data, it will see the pointer at what
> appears to the the right place and believe that no xrun has
> occured. the only way around this is to provide either:
> 
> 	* h/w pointer position as a steadily incrementing value
> 	* h/w pointer position *plus* interrupt count
> 
> i favor the latter since it provides for a longer time before wrapping
> becomes an issue (ULONG_MAX interrupts).

The ALSA internal code already uses hw_ptr and appl_ptr within range 0 to
boundary, where boundary is close to ULONG_MAX and expression boundary / 
period_size == an integer value. So, the hardware pointer also contains 
count of hardware interrupts as well.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en

Re: smix plugin available?

[Paul Davis]

>> actually, it can't. if the user space application is delayed for
>> precisely 1 buffer's worth of data, it will see the pointer at what
>> appears to the the right place and believe that no xrun has
>> occured. the only way around this is to provide either:
>> 
>> 	* h/w pointer position as a steadily incrementing value
>> 	* h/w pointer position *plus* interrupt count
>> 
>> i favor the latter since it provides for a longer time before wrapping
>> becomes an issue (ULONG_MAX interrupts).
>
>The ALSA internal code already uses hw_ptr and appl_ptr within range 0 to
>boundary, where boundary is close to ULONG_MAX and expression boundary / 
>period_size == an integer value. So, the hardware pointer also contains 
>count of hardware interrupts as well.

i know that. my point was that wraparound happens much earlier than if
we used a two part system (pointer-in-buffer + interrupt count). this
would be a similar system to the one used by the RTC, btw. we wouldn't
wrap with a two part system for around 66 days with 64 frames/period
at 48kHz. in the current system we wrap in about 1 day or so.

it doesn't make much difference either way, i was just pointing out a
different way to do it, and more importantly, correcting the claim
that by knowing where the h/w pointer is *in the buffer*, the
application can know if there has been an xrun. the ALSA API h/w
pointer, as you point out, implicitly contains the interrupt count,
but its not as raw as was being requested.

its also worth noting that it too is not immune from missing xruns,
but there isn't anything we can do about kernel/driver code that
blocks interrupts for an entire buffer :(

--p


-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en

Re: buffer sizes

[Mark Swanson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On November 27, 2002 10:04 am, Paul Davis wrote:
> its also worth noting that it too is not immune from missing xruns,
> but there isn't anything we can do about kernel/driver code that
> blocks interrupts for an entire buffer :(

I do not know how long an entire buffer is. I assume this will differ per 
card, but how small could the worst-case possibly be?

Thanks.

- -- 
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE95iCnBtoFHHwdJ/cRAqM2AKCa5BFltV8jnaLXQJkS/hJhqEQ3TgCgqDKT
SUPdKVv9CSf12eSwMd1SoY4=
=XfiU
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en

Re: Re: buffer sizes

[Paul Davis]

>> its also worth noting that it too is not immune from missing xruns,
>> but there isn't anything we can do about kernel/driver code that
>> blocks interrupts for an entire buffer :(
>
>I do not know how long an entire buffer is. I assume this will differ per 
>card, but how small could the worst-case possibly be?

the software gets to configure it. typical values range from 128
frames to 8192 frames, so at 48kHz, that would be 2.6ms to 170ms.

--p


-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en