New PCM API extension

New PCM API extension

[Jaroslav Kysela]

Hello all,

	I'd like to announce a new PCM API extension. Although it is 
implemented, it might be changed following the discussion on this list.
	I've added the snd_pcm_forward() function. This function is
function with opposite meaning to snd_pcm_rewind() - it skips given count
of frames (note that in the ring buffer are unchanged, only the r/w
pointer is increased). The application has full control on the r/w pointer
now. It's useful mainly in the no-xrun mode where the stream runs forever.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Lynx Studio LynxTwo/L22 Driver

[Robert Robinson]

Is anyone working on a driver for the LynxTwo or L22 soundcards ?
Robert Robinson


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: Lynx Studio LynxTwo/L22 Driver

[D. Sen]

I think Opensound is working on a commercial driver. Would be awesome to 
have ALSA support though...

Robert Robinson wrote:
> Is anyone working on a driver for the LynxTwo or L22 soundcards ?
> Robert Robinson
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 
> 




-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php

Re: Lynx Studio LynxTwo/L22 Driver

[D. Sen]

I think Opensound is working on a commercial driver. Would be awesome to 
have ALSA support though...

Robert Robinson wrote:
> Is anyone working on a driver for the LynxTwo or L22 soundcards ?
> Robert Robinson
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 
> 




-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php

Re: Lynx Studio LynxTwo/L22 Driver

[Giuliano Pochini]

Docs/drivers for the LynxTwo are released only under NDA, and the agreement
doesn't allow the subscriber to release a driver in source code form. I
don't thing you'll see an ALSA driver for that card anytime soon.

-- 
Bye.
   Giuliano.



On Sun, 22 Jun 2003 10:07:11 +1000
"D. Sen" <dsen@homemail.com> wrote:

> I think Opensound is working on a commercial driver. Would be awesome to 
> have ALSA support though...
> 
> Robert Robinson wrote:
> > Is anyone working on a driver for the LynxTwo or L22 soundcards ?
> > Robert Robinson



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php

Re: Lynx Studio LynxTwo/L22 Driver

[D. Sen]

Here's a question....

Does Alsa drivers *have* to be in source code form? Can someone not 
release an object file for linking....

They could even make a $ or two out of that if this were possible....

DS.

Giuliano Pochini wrote:
> Docs/drivers for the LynxTwo are released only under NDA, and the agreement
> doesn't allow the subscriber to release a driver in source code form. I
> don't thing you'll see an ALSA driver for that card anytime soon.
> 




-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php

Re: Lynx Studio LynxTwo/L22 Driver

[D. Sen]

Here's a question....

Does Alsa drivers *have* to be in source code form? Can someone not 
release an object file for linking....

They could even make a $ or two out of that if this were possible....

DS.

Giuliano Pochini wrote:
> Docs/drivers for the LynxTwo are released only under NDA, and the agreement
> doesn't allow the subscriber to release a driver in source code form. I
> don't thing you'll see an ALSA driver for that card anytime soon.
> 




-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php

Re: New PCM API extension

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> Hello all,
> 
>         I'd like to announce a new PCM API extension. Although it is
> implemented, it might be changed following the discussion on this list.
>         I've added the snd_pcm_forward() function. This function is
> function with opposite meaning to snd_pcm_rewind() - it skips given count
> of frames (note that in the ring buffer are unchanged, only the r/w
> pointer is increased). The application has full control on the r/w pointer
> now. It's useful mainly in the no-xrun mode where the stream runs forever.

Don't we had already snd_pcm_reset for exactly the same purpose?

What do you expect from this new function that it's not feasible now?

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: New PCM API extension

[Jaroslav Kysela]

On Sat, 22 Feb 2003, Abramo Bagnara wrote:

> Jaroslav Kysela wrote:
> > 
> > Hello all,
> > 
> >         I'd like to announce a new PCM API extension. Although it is
> > implemented, it might be changed following the discussion on this list.
> >         I've added the snd_pcm_forward() function. This function is
> > function with opposite meaning to snd_pcm_rewind() - it skips given count
> > of frames (note that in the ring buffer are unchanged, only the r/w
> > pointer is increased). The application has full control on the r/w pointer
> > now. It's useful mainly in the no-xrun mode where the stream runs forever.
> 
> Don't we had already snd_pcm_reset for exactly the same purpose?

Yes and no. You cannot fill the buffer ahead without writting some
samples. I think that it's not bad to offer the full control on appl_ptr.
It doesn't cost us anything and I can imagine some special applications
where the buffer is auto-silenced that they need to write samples into the
specific position. Reset is nice, but you cannot tell the count of frames
to be skipped without filling.

I'm also going to propose next extension: Actually, the appl_ptr managing
routines - snd_pcm_reset(), snd_pcm_rewind(), snd_pcm_forward() always
uses an ioctl for it's operation. I think that it wouldn't be a bad idea
to implement these function in the lightweight variant, too. I mean that
they will operate only with the actual hw_ptr without calling the kernel
code. We have already functions to synchronize the hw_ptr with the
hardware (snd_pcm_delay(), snd_pcm_hwsync()). Because it's late to change
this behaviour in alsa-lib, I propose to create a function 
'snd_pcm_fast_rw_change()' (better name?) which tells the alsa-lib that no 
accurate operation is required. Especially lowlatency applications will 
benefit that we removed more 'user<->kernel' switches.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: New PCM API extension

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Sat, 22 Feb 2003, Abramo Bagnara wrote:
> 
> > Jaroslav Kysela wrote:
> > >
> > > Hello all,
> > >
> > >         I'd like to announce a new PCM API extension. Although it is
> > > implemented, it might be changed following the discussion on this list.
> > >         I've added the snd_pcm_forward() function. This function is
> > > function with opposite meaning to snd_pcm_rewind() - it skips given count
> > > of frames (note that in the ring buffer are unchanged, only the r/w
> > > pointer is increased). The application has full control on the r/w pointer
> > > now. It's useful mainly in the no-xrun mode where the stream runs forever.
> >
> > Don't we had already snd_pcm_reset for exactly the same purpose?
> 
> Yes and no. You cannot fill the buffer ahead without writting some
> samples. I think that it's not bad to offer the full control on appl_ptr.

"You cannot fill the buffer without writing some samples?" ???

I don't understand what you mean.

> It doesn't cost us anything and I can imagine some special applications

Apart that we have better things to do than to design solutions
searching for problem to solve.

Is not better to wait for the true problem(s) to show up and then try to
design the better solution for a definite class of problems?

> where the buffer is auto-silenced that they need to write samples into the
> specific position. Reset is nice, but you cannot tell the count of frames
> to be skipped without filling.

However I think that auto-silence is not the best thing we've designed.

We're using an interrupt handler to do what a rt-like user space process
should do.

We'd have many things that might be solvable (like saturation in dmix by
example) in this way, but we've (rightly) choosen not to do it to
respect the general principle "never do in kernel space what is doable
in user space".

Sometimes I think that auto silence is an unfortunate exception and I'd
prefer we'd try to move in the opposite direction.

> I'm also going to propose next extension: Actually, the appl_ptr managing
> routines - snd_pcm_reset(), snd_pcm_rewind(), snd_pcm_forward() always
> uses an ioctl for it's operation. I think that it wouldn't be a bad idea
> to implement these function in the lightweight variant, too. I mean that
> they will operate only with the actual hw_ptr without calling the kernel
> code. We have already functions to synchronize the hw_ptr with the
> hardware (snd_pcm_delay(), snd_pcm_hwsync()). Because it's late to change
> this behaviour in alsa-lib, I propose to create a function
> 'snd_pcm_fast_rw_change()' (better name?) which tells the alsa-lib that no
> accurate operation is required. Especially lowlatency applications will
> benefit that we removed more 'user<->kernel' switches.

Note that the assumption of monotonic direction of appl_ptr is spread
everywhere so I doubt that this is feasible for snd_pcm_rewind.

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: New PCM API extension

[Paul Davis]

>> where the buffer is auto-silenced that they need to write samples into the
>> specific position. Reset is nice, but you cannot tell the count of frames
>> to be skipped without filling.
>
>However I think that auto-silence is not the best thing we've designed.
>
>We're using an interrupt handler to do what a rt-like user space process
>should do.
>
>We'd have many things that might be solvable (like saturation in dmix by
>example) in this way, but we've (rightly) choosen not to do it to
>respect the general principle "never do in kernel space what is doable
>in user space".
>
>Sometimes I think that auto silence is an unfortunate exception and I'd
>prefer we'd try to move in the opposite direction.

i think that its similar to the discussion we had 2 weeks ago about
callbacks abramo. alsa-lib could provide functions to do auto-silence,
but the question remains: where and when are they called? the kernel
provides a clearly defined point of control where this can happen if
the user has asked for it and its needed. trying to do it in user
space is clearly a nicer idea, but its hard to see where it should
happen, or how to make sure it does happen if it has been requested.


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: New PCM API extension

[Jaroslav Kysela]

On Sun, 23 Feb 2003, Abramo Bagnara wrote:

> Jaroslav Kysela wrote:
> > 
> > On Sat, 22 Feb 2003, Abramo Bagnara wrote:
> > 
> > > Jaroslav Kysela wrote:
> > > >
> > > > Hello all,
> > > >
> > > >         I'd like to announce a new PCM API extension. Although it is
> > > > implemented, it might be changed following the discussion on this list.
> > > >         I've added the snd_pcm_forward() function. This function is
> > > > function with opposite meaning to snd_pcm_rewind() - it skips given count
> > > > of frames (note that in the ring buffer are unchanged, only the r/w
> > > > pointer is increased). The application has full control on the r/w pointer
> > > > now. It's useful mainly in the no-xrun mode where the stream runs forever.
> > >
> > > Don't we had already snd_pcm_reset for exactly the same purpose?
> > 
> > Yes and no. You cannot fill the buffer ahead without writting some
> > samples. I think that it's not bad to offer the full control on appl_ptr.
> 
> "You cannot fill the buffer without writing some samples?" ???
> 
> I don't understand what you mean.

I mean that you cannot skip some frames (move forward in the ring buffer) 
without using the standard functions to transfer samples into/from the 
ring buffer (snd_pcm_writei for example).

> > It doesn't cost us anything and I can imagine some special applications
> 
> Apart that we have better things to do than to design solutions
> searching for problem to solve.
> 
> Is not better to wait for the true problem(s) to show up and then try to
> design the better solution for a definite class of problems?

I think that I have one present problem. It was not possible to write,
something like the dmix plugin does (in the server/client model): Transfer
data to different areas in the ring buffer. Imagine that client1 wants to
write data at the end of the ring buffer (assume that server don't change
the r/w pointer). Then client2 comes with some data to be placed at the
start of the buffer later (server rewinds the stream position). Then
hardware processed a period and client1 wants to continue (server forwards
the stream position at the end of the ring buffer).

I can imagine more examples where "later" samples might be wanted to be
processed before "quick" ones.

> > where the buffer is auto-silenced that they need to write samples into the
> > specific position. Reset is nice, but you cannot tell the count of frames
> > to be skipped without filling.
> 
> However I think that auto-silence is not the best thing we've designed.
> 
> We're using an interrupt handler to do what a rt-like user space process
> should do.
> 
> We'd have many things that might be solvable (like saturation in dmix by
> example) in this way, but we've (rightly) choosen not to do it to
> respect the general principle "never do in kernel space what is doable
> in user space".
> 
> Sometimes I think that auto silence is an unfortunate exception and I'd
> prefer we'd try to move in the opposite direction.

I have sometimes the mixed feeling, too. But I still think that silencing 
is a good and clean API extension which will work for all applications 
(even without RT priorities, because it is not affected by the behaviour 
of the task scheduler).

> > I'm also going to propose next extension: Actually, the appl_ptr managing
> > routines - snd_pcm_reset(), snd_pcm_rewind(), snd_pcm_forward() always
> > uses an ioctl for it's operation. I think that it wouldn't be a bad idea
> > to implement these function in the lightweight variant, too. I mean that
> > they will operate only with the actual hw_ptr without calling the kernel
> > code. We have already functions to synchronize the hw_ptr with the
> > hardware (snd_pcm_delay(), snd_pcm_hwsync()). Because it's late to change
> > this behaviour in alsa-lib, I propose to create a function
> > 'snd_pcm_fast_rw_change()' (better name?) which tells the alsa-lib that no
> > accurate operation is required. Especially lowlatency applications will
> > benefit that we removed more 'user<->kernel' switches.
> 
> Note that the assumption of monotonic direction of appl_ptr is spread
> everywhere so I doubt that this is feasible for snd_pcm_rewind.

I don't understand here. I've looked to the ioctl implementation and there 
are no problems to change appl_ptr in the user space only as well.

						Jaroslav

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





-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: New PCM API extension

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> I think that I have one present problem. It was not possible to write,
> something like the dmix plugin does (in the server/client model): Transfer
> data to different areas in the ring buffer. Imagine that client1 wants to
> write data at the end of the ring buffer (assume that server don't change
> the r/w pointer). Then client2 comes with some data to be placed at the
> start of the buffer later (server rewinds the stream position). Then
> hardware processed a period and client1 wants to continue (server forwards
> the stream position at the end of the ring buffer).
> 
> I can imagine more examples where "later" samples might be wanted to be
> processed before "quick" ones.

Your examples appears a little confused at my eyes, but if I've
understood correctly don't you think this might be solved by
snd_pcm_rewind done by server?

At least this is how it works in pcm_share.

> > > I'm also going to propose next extension: Actually, the appl_ptr managing
> > > routines - snd_pcm_reset(), snd_pcm_rewind(), snd_pcm_forward() always
> > > uses an ioctl for it's operation. I think that it wouldn't be a bad idea
> > > to implement these function in the lightweight variant, too. I mean that
> > > they will operate only with the actual hw_ptr without calling the kernel
> > > code. We have already functions to synchronize the hw_ptr with the
> > > hardware (snd_pcm_delay(), snd_pcm_hwsync()). Because it's late to change
> > > this behaviour in alsa-lib, I propose to create a function
> > > 'snd_pcm_fast_rw_change()' (better name?) which tells the alsa-lib that no
> > > accurate operation is required. Especially lowlatency applications will
> > > benefit that we removed more 'user<->kernel' switches.
> >
> > Note that the assumption of monotonic direction of appl_ptr is spread
> > everywhere so I doubt that this is feasible for snd_pcm_rewind.
> 
> I don't understand here. I've looked to the ioctl implementation and there
> are no problems to change appl_ptr in the user space only as well.

Have you thought what happens if appl_ptr is changed backward during
interrupt handler?

Lock free ring buffer absolute precondition is monotonic direction.

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: New PCM API extension

[Jaroslav Kysela]

On Mon, 24 Feb 2003, Abramo Bagnara wrote:

> Jaroslav Kysela wrote:
> > 
> > I think that I have one present problem. It was not possible to write,
> > something like the dmix plugin does (in the server/client model): Transfer
> > data to different areas in the ring buffer. Imagine that client1 wants to
> > write data at the end of the ring buffer (assume that server don't change
> > the r/w pointer). Then client2 comes with some data to be placed at the
> > start of the buffer later (server rewinds the stream position). Then
> > hardware processed a period and client1 wants to continue (server forwards
> > the stream position at the end of the ring buffer).
> > 
> > I can imagine more examples where "later" samples might be wanted to be
> > processed before "quick" ones.
> 
> Your examples appears a little confused at my eyes, but if I've
> understood correctly don't you think this might be solved by
> snd_pcm_rewind done by server?

And you'll need to commit the same samples later which seems to me quite 
ineffective (extra copy + processing (if required)).

I probably don't explain clearly my point:

We have data for time T, T+1 and T+2. The application might want to write
data in this order: T+1, T, T+2. While we going back to T position, we can
use snd_pcm_rewind(), but going to T+2 (without changing T+1 data)  
requires writting (or commiting) of same samples now. That's exactly what
I want to eliminate.

> At least this is how it works in pcm_share.
> 
> > > > I'm also going to propose next extension: Actually, the appl_ptr managing
> > > > routines - snd_pcm_reset(), snd_pcm_rewind(), snd_pcm_forward() always
> > > > uses an ioctl for it's operation. I think that it wouldn't be a bad idea
> > > > to implement these function in the lightweight variant, too. I mean that
> > > > they will operate only with the actual hw_ptr without calling the kernel
> > > > code. We have already functions to synchronize the hw_ptr with the
> > > > hardware (snd_pcm_delay(), snd_pcm_hwsync()). Because it's late to change
> > > > this behaviour in alsa-lib, I propose to create a function
> > > > 'snd_pcm_fast_rw_change()' (better name?) which tells the alsa-lib that no
> > > > accurate operation is required. Especially lowlatency applications will
> > > > benefit that we removed more 'user<->kernel' switches.
> > >
> > > Note that the assumption of monotonic direction of appl_ptr is spread
> > > everywhere so I doubt that this is feasible for snd_pcm_rewind.
> > 
> > I don't understand here. I've looked to the ioctl implementation and there
> > are no problems to change appl_ptr in the user space only as well.
> 
> Have you thought what happens if appl_ptr is changed backward during
> interrupt handler?

I see only one problem: XRUN detection might fail, but we can add a check 
to the user space the after appl_ptr change, so we will eliminate this 
problem. There might be a problem with hardware using indirect ring 
buffers (CS46xx, emufx), but the slow function will be still available to 
solve these problems as well.

						Jaroslav

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New PCM API extension

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Mon, 24 Feb 2003, Abramo Bagnara wrote:
> 
> > Jaroslav Kysela wrote:
> > >
> > > I think that I have one present problem. It was not possible to write,
> > > something like the dmix plugin does (in the server/client model): Transfer
> > > data to different areas in the ring buffer. Imagine that client1 wants to
> > > write data at the end of the ring buffer (assume that server don't change
> > > the r/w pointer). Then client2 comes with some data to be placed at the
> > > start of the buffer later (server rewinds the stream position). Then
> > > hardware processed a period and client1 wants to continue (server forwards
> > > the stream position at the end of the ring buffer).
> > >
> > > I can imagine more examples where "later" samples might be wanted to be
> > > processed before "quick" ones.
> >
> > Your examples appears a little confused at my eyes, but if I've
> > understood correctly don't you think this might be solved by
> > snd_pcm_rewind done by server?
> 
> And you'll need to commit the same samples later which seems to me quite
> ineffective (extra copy + processing (if required)).

Yes, this is definitely true.

> I probably don't explain clearly my point:
> 
> We have data for time T, T+1 and T+2. The application might want to write
> data in this order: T+1, T, T+2. While we going back to T position, we can
> use snd_pcm_rewind(), but going to T+2 (without changing T+1 data)
> requires writting (or commiting) of same samples now. That's exactly what
> I want to eliminate.

Now I understand perfectly.

When in past I analyzed this I was unable to imagine a real scenario
where this might happens.

To tell you the truth now too I've some difficulties... can you help me?

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New PCM API extension

[Kai Vehmanen]

Hi,

sorry for the late response.

On Sat, 22 Feb 2003, Jaroslav Kysela wrote:

> 	I've added the snd_pcm_forward() function. This function is
> function with opposite meaning to snd_pcm_rewind() - it skips given count
> of frames (note that in the ring buffer are unchanged, only the r/w
> pointer is increased). The application has full control on the r/w pointer
> now. It's useful mainly in the no-xrun mode where the stream runs forever.

I think this is a good addition, especially considering we already have
the rewind function. I actually have some existing no-xrun code, where I
need to do dummy write/reads if the app side is late. pcm_forward() is 
just the thing for handling these scenerios.

-- 
 http://www.eca.cx
 Audio software for Linux!




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: New PCM API extension

[Jaroslav Kysela]

On Thu, 27 Feb 2003, Kai Vehmanen wrote:

> Hi,
> 
> sorry for the late response.
> 
> On Sat, 22 Feb 2003, Jaroslav Kysela wrote:
> 
> > 	I've added the snd_pcm_forward() function. This function is
> > function with opposite meaning to snd_pcm_rewind() - it skips given count
> > of frames (note that in the ring buffer are unchanged, only the r/w
> > pointer is increased). The application has full control on the r/w pointer
> > now. It's useful mainly in the no-xrun mode where the stream runs forever.
> 
> I think this is a good addition, especially considering we already have
> the rewind function. I actually have some existing no-xrun code, where I
> need to do dummy write/reads if the app side is late. pcm_forward() is 
> just the thing for handling these scenerios.

Note that we had and have the snd_pcm_reset() function which sync the r/w 
ptr with the h/w ptr already (thus avail == ring_buffer for playback and 
avail == 0 for capture).

The new function is intended for these applications:

1) real-time networking (UDP) - there is no guarantee the order of 
   received packets; application might do the stream composing directly
   inside the ring buffer (thus avoid one copy) now
2) writing ahead when xrun condition happens (in no xrun mode); the 
   forward function allows to write data ahead of current hw_ptr to 
   decrease possibility of next - very close - xrun
3) accurate stream position, the snd_pcm_reset() function doesn't tell us
   how many frames were skipped; using snd_pcm_forward(), we don't lose
   this information

						Jaroslav

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




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf