Re: [Alsa-user] AD1985 full-duplex(?)

Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Wed, 18 Aug 2004, Florian Schmidt wrote:

> On Wed, 18 Aug 2004 08:27:10 -0700
> Shaya Potter <spotter@cs.columbia.edu> wrote:
> 
> > A question I've asked, but haven't gotten an answer is why do we have
> > to resort to dmix (i.e. something handled in userspace, and hence
> > subject to the scheduler's whims as only one process can have control
> > over the device) instead of being handled by the kernel driver itself
> > (and hence not subject to the scheduler's whims as much)

Really? If you have no new samples for playback, you cannot mix them.
This situation is same for kernel and user space and depends on the 
scheduler.

> I know how much the ALSA developers favor the modular approach having sw
> mixing done in userspace. I think this is suboptimal for several
> reasons:
> 
> 1] the scheduling problems you mentioned

No, the actual dmix implementation does not use mutexes, so rescheduling 
is not required.

> 2] legacy OSS apps need to be run via aoss which still stinks for many
> apps

It's really problem, but it's problem that we need a compatibility with 
broken API (no library at the initial stage of design, so we cannot 
emulate OSS API directly without using hacks).

Also at this time, nobody helped me to improve the liboss (aoss) code in 
some serious way. I ask why? Nobody uses it? Nobody wants this layer 
fully functional?

I have another idea how we can solve this issue - a network sound driver, 
but this will add the scheduling problems including the throughput of the 
network layer, of course.

> 3] the user has to edit configuration files, which is a showstopper for
> newbies and people who have never had to follow a rigorous syntax.

It's not a goal. In 90% of cases, you may simply use plug:dmix device 
which is already defined in the global configuration files.

When integrated lisp is used, we'll solve the remaining 10% hardware 
constraints.

> I would suggest writing another "dummy" soundcard module which would
> sit "ontop" of the normal alsa driver and which does nothing but provide
> sw mixing access [including the needed resampling and mixing]. 

It's not easy task and again, do we need to code it in the kernel space?
Benefits? Target users?

I think that we should provide the functionality (mixing) for all APIs, 
but the latency issues which mixing might invoke are not a serious 
problem. It's similar to graphics cards. You'll get better results with an 
accelerator (in case of sound with hardware having the mixing capability).

						Jaroslav

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


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: [Alsa-user] AD1985 full-duplex(?)

[Florian Schmidt]

On Wed, 18 Aug 2004 19:37:16 +0200 (CEST)
Jaroslav Kysela <perex@suse.cz> wrote:

> > I know how much the ALSA developers favor the modular approach
> > having sw mixing done in userspace. I think this is suboptimal for
> > several reasons:
> > 
> > 1] the scheduling problems you mentioned
> 
> No, the actual dmix implementation does not use mutexes, so
> rescheduling is not required.

I see..

> 
> > 2] legacy OSS apps need to be run via aoss which still stinks for
> > many apps
> 
> It's really problem, but it's problem that we need a compatibility
> with broken API (no library at the initial stage of design, so we
> cannot emulate OSS API directly without using hacks).
> 
> Also at this time, nobody helped me to improve the liboss (aoss) code
> in some serious way. I ask why? Nobody uses it? Nobody wants this
> layer fully functional?

Hmm, you went on to make a wrapper for which the apps need to be changed
at source code level. This is an option which is often not available
[old games with makers who are broke whatever, closed source app where
the vendor just refuses to fix it at all, etc.]. This is why i don't
have any interest in improving it. I do have interest in improving aoss
though wrt the traditional LD_PRELOAD hack..

But fixing the mmap issue was over my head [sorry], so i didn't go after
it further.

> 
> I have another idea how we can solve this issue - a network sound
> driver, but this will add the scheduling problems including the
> throughput of the network layer, of course.
> 
> > 3] the user has to edit configuration files, which is a showstopper
> > for newbies and people who have never had to follow a rigorous
> > syntax.
> 
> It's not a goal. In 90% of cases, you may simply use plug:dmix device 
> which is already defined in the global configuration files.

yes, you're right. Btw: i also think there needs to be a predefined asym
device which makes fullduplex access available for nultiple apps, too..

> 
> > I would suggest writing another "dummy" soundcard module which would
> > sit "ontop" of the normal alsa driver and which does nothing but
> > provide sw mixing access [including the needed resampling and
> > mixing]. 
> 
> It's not easy task and again, do we need to code it in the kernel
> space? Benefits? Target users?
> 
> I think that we should provide the functionality (mixing) for all
> APIs, but the latency issues which mixing might invoke are not a
> serious problem. It's similar to graphics cards. You'll get better
> results with an accelerator (in case of sound with hardware having the
> mixing capability).
> 

Yes. I just am not sure what is easier:

a] fixing aoss to support all legacy oss apps [even those which cannot
be changed at source code level]

b] create a kernel module like the beforementioned which would just
eliminate the issue for most users since they can just use the kernel
level oss emu..

I really am not sure anymore. What do you think?

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Wed, 18 Aug 2004, Florian Schmidt wrote:

> > Also at this time, nobody helped me to improve the liboss (aoss) code
> > in some serious way. I ask why? Nobody uses it? Nobody wants this
> > layer fully functional?
> 
> Hmm, you went on to make a wrapper for which the apps need to be changed
> at source code level. This is an option which is often not available
> [old games with makers who are broke whatever, closed source app where
> the vendor just refuses to fix it at all, etc.]. This is why i don't
> have any interest in improving it. I do have interest in improving aoss
> though wrt the traditional LD_PRELOAD hack..
> 
> But fixing the mmap issue was over my head [sorry], so i didn't go after
> it further.

Yep, but most bug reports are for quake or similar games. I don't play 
them and also I don't have useable supported hardware with the OpenGL, so 
I cannot test them. If you trace the code (I think that open source 
variants have similar OSS code) and create a simple test utility which can 
be run from the command line, I'll try to fix aoss.

> > I have another idea how we can solve this issue - a network sound
> > driver, but this will add the scheduling problems including the
> > throughput of the network layer, of course.
> > 
> > > 3] the user has to edit configuration files, which is a showstopper
> > > for newbies and people who have never had to follow a rigorous
> > > syntax.
> > 
> > It's not a goal. In 90% of cases, you may simply use plug:dmix device 
> > which is already defined in the global configuration files.
> 
> yes, you're right. Btw: i also think there needs to be a predefined asym
> device which makes fullduplex access available for nultiple apps, too..

I agree. Do you have a nice idea for the PCM name? My ideas:

mix
xmulti (we have already multi plugin)
shs (SHared Stream)
shd (SHared Device)

???

> > > I would suggest writing another "dummy" soundcard module which would
> > > sit "ontop" of the normal alsa driver and which does nothing but
> > > provide sw mixing access [including the needed resampling and
> > > mixing]. 
> > 
> > It's not easy task and again, do we need to code it in the kernel
> > space? Benefits? Target users?
> > 
> > I think that we should provide the functionality (mixing) for all
> > APIs, but the latency issues which mixing might invoke are not a
> > serious problem. It's similar to graphics cards. You'll get better
> > results with an accelerator (in case of sound with hardware having the
> > mixing capability).
> > 
> 
> Yes. I just am not sure what is easier:
> 
> a] fixing aoss to support all legacy oss apps [even those which cannot
> be changed at source code level]
> 
> b] create a kernel module like the beforementioned which would just
> eliminate the issue for most users since they can just use the kernel
> level oss emu..

My plan is fix aoss and create a network sound device inside kernel, so we 
can reroute OSS streams from kernel to userspace, too.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Takashi Iwai]

At Thu, 19 Aug 2004 10:58:04 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 18 Aug 2004, Florian Schmidt wrote:
> 
> > > Also at this time, nobody helped me to improve the liboss (aoss) code
> > > in some serious way. I ask why? Nobody uses it? Nobody wants this
> > > layer fully functional?
> > 
> > Hmm, you went on to make a wrapper for which the apps need to be changed
> > at source code level. This is an option which is often not available
> > [old games with makers who are broke whatever, closed source app where
> > the vendor just refuses to fix it at all, etc.]. This is why i don't
> > have any interest in improving it. I do have interest in improving aoss
> > though wrt the traditional LD_PRELOAD hack..
> > 
> > But fixing the mmap issue was over my head [sorry], so i didn't go after
> > it further.
> 
> Yep, but most bug reports are for quake or similar games. I don't play 
> them and also I don't have useable supported hardware with the OpenGL, so 
> I cannot test them. If you trace the code (I think that open source 
> variants have similar OSS code) and create a simple test utility which can 
> be run from the command line, I'll try to fix aoss.

Sigh, quake is always a bad boy...

> > > I have another idea how we can solve this issue - a network sound
> > > driver, but this will add the scheduling problems including the
> > > throughput of the network layer, of course.
> > > 
> > > > 3] the user has to edit configuration files, which is a showstopper
> > > > for newbies and people who have never had to follow a rigorous
> > > > syntax.
> > > 
> > > It's not a goal. In 90% of cases, you may simply use plug:dmix device 
> > > which is already defined in the global configuration files.
> > 
> > yes, you're right. Btw: i also think there needs to be a predefined asym
> > device which makes fullduplex access available for nultiple apps, too..
> 
> I agree. Do you have a nice idea for the PCM name? My ideas:
> 
> mix

I like this one.

> xmulti (we have already multi plugin)
> shs (SHared Stream)
> shd (SHared Device)
> 
> ???
> 
> > > > I would suggest writing another "dummy" soundcard module which would
> > > > sit "ontop" of the normal alsa driver and which does nothing but
> > > > provide sw mixing access [including the needed resampling and
> > > > mixing]. 
> > > 
> > > It's not easy task and again, do we need to code it in the kernel
> > > space? Benefits? Target users?
> > > 
> > > I think that we should provide the functionality (mixing) for all
> > > APIs, but the latency issues which mixing might invoke are not a
> > > serious problem. It's similar to graphics cards. You'll get better
> > > results with an accelerator (in case of sound with hardware having the
> > > mixing capability).
> > > 
> > 
> > Yes. I just am not sure what is easier:
> > 
> > a] fixing aoss to support all legacy oss apps [even those which cannot
> > be changed at source code level]
> > 
> > b] create a kernel module like the beforementioned which would just
> > eliminate the issue for most users since they can just use the kernel
> > level oss emu..
> 
> My plan is fix aoss and create a network sound device inside kernel, so we 
> can reroute OSS streams from kernel to userspace, too.

Can "network sound device" work with the mmap, too?


Takashi


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Florian Schmidt]

On Thu, 19 Aug 2004 10:58:04 +0200 (CEST)
Jaroslav Kysela <perex@suse.cz> wrote:

> > But fixing the mmap issue was over my head [sorry], so i didn't go
> > after it further.
> 
> Yep, but most bug reports are for quake or similar games. I don't play
> them and also I don't have useable supported hardware with the OpenGL,
> so I cannot test them. If you trace the code (I think that open source
> variants have similar OSS code) and create a simple test utility which
> can be run from the command line, I'll try to fix aoss.

I think there are opensourced versions of _some_ of these old games.
I'll take a look. If i don't find anything i'll try to write an oss test
app that uses mmap and fails similarly. 

> > yes, you're right. Btw: i also think there needs to be a predefined
> > asym device which makes fullduplex access available for nultiple
> > apps, too..
> 
> I agree. Do you have a nice idea for the PCM name? My ideas:
> 
> mix
> xmulti (we have already multi plugin)
> shs (SHared Stream)
> shd (SHared Device)

simply "shared" maybe? "mix" doesn't quite fit it, since it only
describes the playback direction and it's maybe too similar to "dmix".
Or stick to the way it was done with the dmix plugin. Call the
predefined device using asym simply "asym".


> > a] fixing aoss to support all legacy oss apps [even those which
> > cannot be changed at source code level]
> > 
> > b] create a kernel module like the beforementioned which would just
> > eliminate the issue for most users since they can just use the
> > kernel level oss emu..
> 
> My plan is fix aoss and create a network sound device inside kernel,
> so we can reroute OSS streams from kernel to userspace, too.

May i ask, why your planning to make this networked? I read some
articles about user space file systems [which get utilized
by kernel modules] a while back. I think that networking introduces
another layer of complexity. You think this is nessecary?

hmm, some links i found in my bookmarks:

http://okmij.org/ftp/syscall-interpose.html
http://www.circlemud.org/~jelson/software/fusd/

regards,
flo


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Thu, 19 Aug 2004, Takashi Iwai wrote:

> Can "network sound device" work with the mmap, too?

I think yes, it can, but the real output will be more delayd. So, it won't 
be much useable for the strict real-time applications.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Thu, 19 Aug 2004, Florian Schmidt wrote:

> May i ask, why your planning to make this networked? I read some
> articles about user space file systems [which get utilized
> by kernel modules] a while back. I think that networking introduces
> another layer of complexity. You think this is nessecary?

It's more interesting development and as bonus we get remote audio 
devices.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

> On Thu, 19 Aug 2004, Takashi Iwai wrote:
>>Can "network sound device" work with the mmap, too?
> I think yes, it can, but the real output will be more delayd. So, it won't 
> be much useable for the strict real-time applications.
But old quake and new quake3 and some OSS apps use mmap mode for better 
timing and accurate mixing so will it be usable if done that way?

As talking about network transparency it is a good idea but what about 
more system independent solution - look at MASS for example
(link from www.x.org).
I personally think that local sound should be done as effective as it 
can be so doing it through network layer is not a nice idea - maybe IPC
and non swappable shared memory should be used to transfer data
between kernel and user space to used ALSA mix/asym advantages.

I have a modified aoss lib which plays quake1 - quake3 and other apps
simulataniously but this is not a perfect solution. Sometimes sound is 
distorted and some apps are not working (these using SDL and poll method
- some time issues probably). This method not supports multichannel
sources (4, 5.1, 7.1) so OSS compatibility is not full.
I need volume regulation per source too which is missing.
OSS emulation in kernel is not fully compatible with OSS too so some 
native OSS apps will not work.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Mon, 23 Aug 2004, Adam Tlałka wrote:

> > On Thu, 19 Aug 2004, Takashi Iwai wrote:
> >>Can "network sound device" work with the mmap, too?
> > I think yes, it can, but the real output will be more delayd. So, it won't 
> > be much useable for the strict real-time applications.
> But old quake and new quake3 and some OSS apps use mmap mode for better 
> timing and accurate mixing so will it be usable if done that way?

I already stated: If you want to use real-time applications, buy real-time 
hardware.

> As talking about network transparency it is a good idea but what about 
> more system independent solution - look at MASS for example
> (link from www.x.org).
> I personally think that local sound should be done as effective as it 
> can be so doing it through network layer is not a nice idea - maybe IPC
> and non swappable shared memory should be used to transfer data
> between kernel and user space to used ALSA mix/asym advantages.

We can do a similar extension like xshm in X-window in the network sound 
driver. You need always a "control" channel between kernel and user space.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

> On Mon, 23 Aug 2004, Adam Tlałka wrote:
> 
> 
>>>On Thu, 19 Aug 2004, Takashi Iwai wrote:
>>>
>>>>Can "network sound device" work with the mmap, too?
>>>
>>>I think yes, it can, but the real output will be more delayd. So, it won't 
>>>be much useable for the strict real-time applications.
>>
>>But old quake and new quake3 and some OSS apps use mmap mode for better 
>>timing and accurate mixing so will it be usable if done that way?
> 
> 
> I already stated: If you want to use real-time applications, buy real-time 
> hardware.
They are rather normal user applications then specialized RT apps - I 
don't want to buy specialized hardware just to play some games
or mix system sounds with browser and communicator apps sounds.
Also switching two, 4 or 5.1 mode and headphone mode should be done
just by one click without application restarting. So down/up mixing
should be in a driver. I think it can't be done with todays ALSA in lib 
functionality approach and never will be.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Mon, 23 Aug 2004, Adam Tlałka wrote:

> > I already stated: If you want to use real-time applications, buy real-time 
> > hardware.
> They are rather normal user applications then specialized RT apps - I 
> don't want to buy specialized hardware just to play some games
> or mix system sounds with browser and communicator apps sounds.

Quake is special case. For standard applications, the mixing should be 
provided, but there're not latency issues.

I still think that the aoss library can be fixed so that quake will work.
I think that OSS/Commercial also adds some delay on their "virtual" 
devices mixed together.

> Also switching two, 4 or 5.1 mode and headphone mode should be done
> just by one click without application restarting. So down/up mixing
> should be in a driver. I think it can't be done with todays ALSA in lib 
> functionality approach and never will be.

Why not? Most today's hardware can reroute samples or analog paths in 
hardware. So it's only about right mixer setup.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Takashi Iwai]

At Mon, 23 Aug 2004 13:36:02 +0200,
Adam Tlałka wrote:
> 
> > On Thu, 19 Aug 2004, Takashi Iwai wrote:
> >>Can "network sound device" work with the mmap, too?
> > I think yes, it can, but the real output will be more delayd. So, it won't 
> > be much useable for the strict real-time applications.
> But old quake and new quake3 and some OSS apps use mmap mode for better 
> timing and accurate mixing

I doubt it.

Mmap doesn't provide better nor accurate "timing" although it provides
more efficient data transfer method.  The accuracy depends on the
fineness of DMA interrupts and the scheduler latency.

I don't see so big requirement of mmap in this regard.  If you need a
free-running ring buffer, you can do it simply by setting the proper
stop_threshold for disabling XRUN detection.  The perfomance win by
mmap is far little in comparison with computations of mixing and
effects.  Hence, what I see here is only the demand of
"compatibility".  From the performance perspective, there is no reason
to force mmap.

Note that I don't mention here about apps with high bandwidth like
HDR but apps with normal 16bit/48k sounds with at most 6 voices in the
background.

Also, I don't mean that network system can provide as good response as
the normal system.  What I mean is that the discussion of latency
should be indepdent from necessity of mmap implementaion.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Mon, Aug 23, 2004 at 04:39:20PM +0200, Jaroslav Kysela wrote:
> Quake is special case. For standard applications, the mixing should be 
> provided, but there're not latency issues.
OK - but some old apps use DMA ring buffer and they should work properly
too.

> 
> I still think that the aoss library can be fixed so that quake will work.
> I think that OSS/Commercial also adds some delay on their "virtual" 
> devices mixed together.
Sure but aoss sometimes produces clicks and bad sound effects.
Switching to other app and then returning to previous one helps.
I have patched aoss which plays quake1 - quake3 in MMAP mode
but it is not perfect. Also some apps which use poll don't work
at all (old game Shogo) - SDL report timing problems and disables
sound.
aoss approach doesn't work at all with apss which are completly static
or disabling LD_PRELOAD.

> Why not? Most today's hardware can reroute samples or analog paths in 
> hardware. So it's only about right mixer setup.
As I said before I dont want to buy expensive mambo-jubo card just 
to mix stereo, mono and 5.1 sources together at the same time
with the proper up/down sampling, channel volume control
and sound phase correction. I think that driver should use all card
abilities and emulate other in software.
If I put headphones on my head I just want to use one switch in mixer
app to turn on headphones mode. The same in opposite direction.


Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

[2004-08-23 17:30] Takashi Iwai:
>>>>Can "network sound device" work with the mmap, too?
>>>I think yes, it can, but the real output will be more delayd. So, it won't 
>>>be much useable for the strict real-time applications.
If "network" mode for OSS ALSA emulation in kernel will give us worse
results than real OSS then I prefer to use real OSS drivers :-(
- on the same machine. Playing quake or other MMAP mode games with
networked sound  is not a real target anyway.

> effects.  Hence, what I see here is only the demand of
> "compatibility".  From the performance perspective, there is no reason
> to force mmap.
Of course I agree with that. It can't be perfect because of emulation but
should be here for some old apps - and should work properly with them.


I imagine sound system as some layered structure:

program
|
v
dev -> redirecting, routing and up/down mixing kernel layer
                |                                           |
                v                                           v
           kernel device driver                       net
                |
                v
           hardware

in ALSA it looks like

program
|
v
alsalib (plugins for routing, resampling and mixing) -> kernel driver -> 
hardware
                                                                    -> 
net (in the future)

I prefer normal Unix way (device and standard functions plus ioctl) so 
if we can
do a kernel module which does routing, redirecting and resampling on top of
free OSS module we could obtain full functionality without any change
in OSS programs.  But that's OSS not ALSA.

In ALSA we need some kernel module which routes virtual OSS channels from
kernel space to user space in ALSA lib emulation. I don't know how effective
it will be but if we decided to mix in lib then this is the only way.

By the way in ALSA README we read about full OSS ALSA compatibility.
But this is not true!!!
No mixer calls on dsp stream, no multichannel streams (4...7.1)
are possible with OSS emulation, DMA mode broken.
I just can't abandon using OSS because of that :-(.

There are many sound daemons apps.
I just don't want to link an app with all their libraries. It should 
just open
and use sound device - kernel module should communicate with deamon
to hide its presence before an app - that is the proper way IMHO.
Standard Unix approach plus some message passing method if we can't
do all in kernel.

So what is the future of Linux sound??

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Sat, 28 Aug 2004, Adam Tlałka wrote:

> I imagine sound system as some layered structure:
> 
> program
> |
> v
> dev -> redirecting, routing and up/down mixing kernel layer
>                 |                                           |
>                 v                                           v
>            kernel device driver                       net
>                 |
>                 v
>            hardware

It's kernel centristic view. I don't see much reasons to have everything 
in kernel.

> in ALSA it looks like
> 
> program
> |
> v
> alsalib (plugins for routing, resampling and mixing) -> kernel driver -> 
> hardware
>                                                                     -> 
> net (in the future)

What about this direct way: program -> alsa-lib -> net ?
I proposed network driver mainly to solve OSS redirecting problems.
We can implement this driver completely in user space.

> I prefer normal Unix way (device and standard functions plus ioctl) so
> if we can do a kernel module which does routing, redirecting and
> resampling on top of free OSS module we could obtain full functionality
> without any change in OSS programs.  But that's OSS not ALSA.
> 
> In ALSA we need some kernel module which routes virtual OSS channels
> from kernel space to user space in ALSA lib emulation. I don't know how
> effective it will be but if we decided to mix in lib then this is the
> only way.
> 
> By the way in ALSA README we read about full OSS ALSA compatibility.
> But this is not true!!!
> No mixer calls on dsp stream,

Huh, that's new for me. It does not work? It's implemented.

> no multichannel streams (4...7.1) are possible with OSS emulation,

Additional information which is moved to alsa-lib is required. Anyway,
actually almost all new applications requiring this feature support ALSA.

> DMA mode broken. I just can't abandon using OSS because of that :-(.

Could you specify which is broken with the kernel ALSA's OSS mmap 
emulation?

> There are many sound daemons apps. I just don't want to link an app with
> all their libraries. It should just open and use sound device - kernel
> module should communicate with deamon to hide its presence before an app
> - that is the proper way IMHO. Standard Unix approach plus some message
> passing method if we can't do all in kernel.
> 
> So what is the future of Linux sound??

Note that the direct device access is the major problem with the OSS API.
If a library which hide the direct syscalls exists, we never had such 
problems to redirect OSS calls to our code. The library can be very 
small. I already wrote an OSS redirector (alsa-oss/oss-redir) but it might 
be that this project will be totaly ignored, because I am not able to
do much advertisements for all OSS developers to use these calls rather 
than direct device accesses.

I feel that it's mainly about fixing bugs. Unfortunately, most of users
(including you) point me to quake binaries. I cannot run them on my
machines. The installation always fails at some point (OpenGL, missing
.wad files for full quake version etc.). If you show me a little command
style code which triggers different bugs in the OSS emulation layer, I
promise, I will fix them.

Anyway, this call is to all people on this list. Could you create a Wiki
page which exact (version, source URL) OSS applications have trouble with:

1) ALSA's kernel OSS emulation
2) ALSA's aoss (libaoss)

It will also help me a lot to finish the OSS emulation and stop these 
complains.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

[2004-08-29 11:54] Jaroslav Kysela:
> On Sat, 28 Aug 2004, Adam Tlałka wrote:
> 
> 
>>I imagine sound system as some layered structure:
>>
>>program
>>|
>>v
>>dev -> redirecting, routing and up/down mixing kernel layer
>>                |                                           |
>>                v                                           v
>>           kernel device driver                       net
>>                |
>>                v
>>           hardware
> 
> 
> It's kernel centristic view. I don't see much reasons to have everything 
> in kernel.
Because of latency issues and need for direct access to hardware
it's sometimes better to have this functions in kernel - if card
can mix in hardware N streams use that feature for N streams but if you 
need N+1
then you must do it in software. If again streams count lowers to N you 
should
return to hardware mixing. I can't see this is possible with current 
ALSA dmix
plugin.

> What about this direct way: program -> alsa-lib -> net ?
> I proposed network driver mainly to solve OSS redirecting problems.
> We can implement this driver completely in user space.
OK it was my error - bad spaceing - you are right.

>>No mixer calls on dsp stream,
> Huh, that's new for me. It does not work? It's implemented.
Maybe with kernel emulation, but not in aoss.

>>no multichannel streams (4...7.1) are possible with OSS emulation,
> Additional information which is moved to alsa-lib is required. Anyway,
> actually almost all new applications requiring this feature support ALSA.
OK, but OSS compability is not full.

>>DMA mode broken. I just can't abandon using OSS because of that :-(.
> Could you specify which is broken with the kernel ALSA's OSS mmap 
> emulation?
I am not using kernel module. I am using patched aoss lib and dmix plugin.
I think that we should carefully read OSS pdf doc and look at the OSS
emulation code to find which is not compatible with documented original
OSS behaviour.
As I can tell there is one thing according to DMA mode - buffer size and
number of periods. In original OSS for example GETOSPACE call reports
these values and after that call or any of GETxPTR, GETxDELAY, read
or write operation these values are fixed. So if an app read buffer size
and num of periods first and then sets stream parameters (format, stereo,
rate) buffer size and num of periods are not changed - in original OSS.
If we changing parameters using ALSA lib buffer size and num of periods 
could
change so if we now have different OSS values some apps just broke.
OK - this app behaviour is not quite correct - it should set stream 
parameters
first and ask about buffer size after that. But this is an original OSS 
documented
behaviour so it should be supported.

> Note that the direct device access is the major problem with the OSS API.
I don't think so. You don't need to link an app with any additional 
libraries
and these device open, read, write, select, poll and ioctl are just normal
Unix filesystem calls. We only should have kernel module which could 
redirect
data stream and control to user space (maybe RT) daemon which does the rest.

program -> OSS dev -> redirector module -> special RT daemon -> alsa lib 
-> card

> If a library which hide the direct syscalls exists, we never had such 
> problems to redirect OSS calls to our code. The library can be very 
> small.
But we have some closed source proprietary apps which should work too.

> I feel that it's mainly about fixing bugs. Unfortunately, most of users
> (including you) point me to quake binaries. I cannot run them on my
> machines.
Hmm, I am frequently testing aoss with quake.x11 (quake1) binary which 
is plain X11
app - no OpenGL. I don't now how is accesible quake2 in your country
but I just bought cheap CD with full version in some multimedia store.
quake1 and quake2 program sources are accesible on the net.

> Anyway, this call is to all people on this list. Could you create a Wiki
> page which exact (version, source URL) OSS applications have trouble with:
> 
> 1) ALSA's kernel OSS emulation
> 2) ALSA's aoss (libaoss)
OK if I find some time and test this more I write some info.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Sun, 29 Aug 2004, Adam Tlałka wrote:

> Because of latency issues and need for direct access to hardware it's
> sometimes better to have this functions in kernel - if card can mix in
> hardware N streams use that feature for N streams but if you need N+1
> then you must do it in software. If again streams count lowers to N you
> should return to hardware mixing. I can't see this is possible with
> current ALSA dmix plugin.

It can be implemented also in the user space. If open() of raw hw:X,Y 
device fails, then dmix can be used. We can eventually use a threshold
to leave some voices for wavetable etc.

> >>No mixer calls on dsp stream,
> > Huh, that's new for me. It does not work? It's implemented.
> Maybe with kernel emulation, but not in aoss.

OK, it's right. Please, make a bugreport.

> >>no multichannel streams (4...7.1) are possible with OSS emulation,
> > Additional information which is moved to alsa-lib is required. Anyway,
> > actually almost all new applications requiring this feature support ALSA.
> OK, but OSS compability is not full.

Yes, I fixed README which was very old.

> >>DMA mode broken. I just can't abandon using OSS because of that :-(.
> > Could you specify which is broken with the kernel ALSA's OSS mmap 
> > emulation?
>
> I am not using kernel module. I am using patched aoss lib and dmix
> plugin. I think that we should carefully read OSS pdf doc and look at
> the OSS emulation code to find which is not compatible with documented
> original OSS behaviour. As I can tell there is one thing according to
> DMA mode - buffer size and number of periods. In original OSS for
> example GETOSPACE call reports these values and after that call or any
> of GETxPTR, GETxDELAY, read or write operation these values are fixed.
> So if an app read buffer size and num of periods first and then sets
> stream parameters (format, stereo, rate) buffer size and num of periods
> are not changed - in original OSS. If we changing parameters using ALSA
> lib buffer size and num of periods could change so if we now have
> different OSS values some apps just broke. OK - this app behaviour is
> not quite correct - it should set stream parameters first and ask about
> buffer size after that. But this is an original OSS documented behaviour
> so it should be supported.

Yes, some test utilities will be fine.

> > Note that the direct device access is the major problem with the OSS API.

> I don't think so. You don't need to link an app with any additional
> libraries and these device open, read, write, select, poll and ioctl are
> just normal Unix filesystem calls. We only should have kernel module
> which could redirect data stream and control to user space (maybe RT)
> daemon which does the rest.

I meant that the library had to be used from the initial stage of the OSS 
API design like we have alsa-lib. Yes, now is too late at least for static 
linked applications.

> program -> OSS dev -> redirector module -> special RT daemon -> alsa lib 
> -> card

I would replace redirector module with network or direct loopback 
driver module. In this case ALSA applications can benefit as well.

> > If a library which hide the direct syscalls exists, we never had such 
> > problems to redirect OSS calls to our code. The library can be very 
> > small.
> But we have some closed source proprietary apps which should work too.

Yes, bad initial API design.

> > I feel that it's mainly about fixing bugs. Unfortunately, most of users
> > (including you) point me to quake binaries. I cannot run them on my
> > machines.
> Hmm, I am frequently testing aoss with quake.x11 (quake1) binary which 
> is plain X11
> app - no OpenGL. I don't now how is accesible quake2 in your country
> but I just bought cheap CD with full version in some multimedia store.
> quake1 and quake2 program sources are accesible on the net.

If we have the sources, could you extract the audio code and prepare a 
short test command line code? It would be very useful for debugging.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Peter Zubaj]

Hi,

Why not create some kind of sound server (again sound server :-)) with
alsa-lib API on both sides. Some combination of dmix and dsnoop.
I don't think that most of users needs low latency provided by dmix.
Most of users need software mixing, something to be able to do
upmixing (down mixing) from 2 -> 5.1 and ability to record in more
then 1 app and maybe bass/treble (equalizer). This server can use hw
mixing too, if it is provided by sound card. This can be like virtual
soundcard, but in userspace.

Still, you will be able to route output from this sound server to dmix
plugin.

I think, you can do this with alsa-lib API. Actually I started look
after this, but I don't have enought free time.

Later softmidi synth can by added too. If someone need something
better (low latency, ...), he can use hw directly.

Peter Zubaj
____________________________________
http://www.pobox.sk/ - najvacsi slovensky freemail





-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Tue, 31 Aug 2004, Peter Zubaj wrote:

> Hi,
> 
> Why not create some kind of sound server (again sound server :-)) with
> alsa-lib API on both sides. Some combination of dmix and dsnoop.
> I don't think that most of users needs low latency provided by dmix.
> Most of users need software mixing, something to be able to do
> upmixing (down mixing) from 2 -> 5.1 and ability to record in more
> then 1 app and maybe bass/treble (equalizer). This server can use hw
> mixing too, if it is provided by sound card. This can be like virtual
> soundcard, but in userspace.

Yes, we might end up with this solution.

Anyway, the problem now is to reroute data from the kernel driver back to 
user space. My ideas are:

1) use ALSA API also from the back side (capture direction); we have
   already very efficient transfer method and sharing one ring buffer for
   both playback (application) and capture (mixing daemon) is possible
2) use universal control API to pass messages like stream parameters etc.
3) clocking
   - synced to system time clock (probably jiffies) - for no real playback
   - or use the slave PCM timer for the real output devices

It seems that many parts of the current dummy driver can be reused.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

Hi,

I am testing modified aoss library.
To satisfy OSS compatibility I defined fixed OSS buffer (64KiB).
So we have two buffers: ALSA ring buffer and emulated OSS ring buffer.
Read/write normal modes are unchanged but in DMA mode we must copy the
first buffer contents to the second. To satisfy low latency I copy data
from hw pointer position so any changes in OSS DMA buffer should be
quickly propagated to ALSA buffer. I can't just fill whole ALSA buffer
and then fill available space at every period because data could change
just several samples after hw position. So I am doing snd_pcm_mmap_begin
and snd_pcm_commit functions to move appl pointer in ALSA ring buffer
so it is all filled 
(alsa_hw_ptr % alsa.buffer_size == alsa_appl_ptr % alsa.buffer_size)
and then calculate oss_hw_ptr as oss_appl_ptr - alsa.buffer_size.
Now I can copy the data (size = alsa.buffer_size - alsa.period_size).
So far it works with Q1, Q2 and Q3. Copying less data not always works
properly - sound is distorted.

IMHO DMA mmaped mode in ALSA is not as easy to use as OSS DMA mode.
All we need is theoretically only the hw pointer position in DMA ring buffer 
to properly mix data from different events. But in ALSA we must
calculate it doing additional calls. Some functions like snd_pcm_delay
in normal DMA mode seems to be not needed. An app needs only ring buffer
hw position. Doing normal system call it can obtain current system time
so it can calculate the delay and correct sample position to mix.
In ALSA we should move appl pointer using mmap_begin and then mmap_commit
functions to avoid buffer underrun and calculate hw pointer manually
to know where mix the new data. So I think there is more to do then in
OSS case and more to do in the wrong way. I will send my sources
after more testing.

I have some questions. If I get delay < 0 and then do
err = snd_pcm_forward(pcm,-delay) what err returned value really means
(I am using dmix and of course rate plugins)?
How interpret err <= 0 value?
Also what is the meaning of snd_pcm_available > alsa.buffer_size?

Regards

-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Mon, 6 Sep 2004, Adam Tla/lka wrote:

> IMHO DMA mmaped mode in ALSA is not as easy to use as OSS DMA mode.
> All we need is theoretically only the hw pointer position in DMA ring buffer 
> to properly mix data from different events. But in ALSA we must
> calculate it doing additional calls. Some functions like snd_pcm_delay
> in normal DMA mode seems to be not needed. An app needs only ring buffer
> hw position. Doing normal system call it can obtain current system time
> so it can calculate the delay and correct sample position to mix.

There is always a drift between system and card's timing.

> In ALSA we should move appl pointer using mmap_begin and then mmap_commit

The appl_ptr is not moved in mmap_begin. The mmap_begin function only 
returns the actual position to ring buffer based on appl_ptr.

> functions to avoid buffer underrun and calculate hw pointer manually
> to know where mix the new data. So I think there is more to do then in
> OSS case and more to do in the wrong way. I will send my sources
> after more testing.

We need the intelligent mmap transport for additional functionality 
(conversions, resampling etc.). I think it's the proper way and nobody 
(except OSS emulation) has the useability problem. You can still move 
backwards (although it is problematic when you have a mixing on the path).

> I have some questions. If I get delay < 0 and then do
> err = snd_pcm_forward(pcm,-delay) what err returned value really means
> (I am using dmix and of course rate plugins)?
> How interpret err <= 0 value?

err < 0 -> error code
err == 0 -> no action (appl_ptr was unchanged in case when you're already 
behind hw_ptr)

> Also what is the meaning of snd_pcm_available > alsa.buffer_size?

You're too late, so you need to fill (or better skip via forward) some 
more samples to synchronize appl_ptr.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Tue, Sep 07, 2004 at 11:05:05AM +0200, Jaroslav Kysela wrote:
> On Mon, 6 Sep 2004, Adam Tla/lka wrote:
> There is always a drift between system and card's timing.
ALSA appl/hw_ptr calculated position is also not exact ;-).
If I know system time and card hw_ptr it is enough to calculate desired
position and correct time drift. 

> The appl_ptr is not moved in mmap_begin. The mmap_begin function only 
> returns the actual position to ring buffer based on appl_ptr.
That's right. I do mmap_begin to obtain appl offset in ALSA buffer
and mmap_commit to move the appl pointer so we have no buffer
underrun and appl offset is equal to hw offset (approximately).
Now I can update the ALSA buffer from OSS buffer.

> We need the intelligent mmap transport for additional functionality 
> (conversions, resampling etc.). I think it's the proper way and nobody 
> (except OSS emulation) has the useability problem. You can still move 
> backwards (although it is problematic when you have a mixing on the path).
As I wrote before I use dmix plugin and of course there is a route
plugin on the path so moving backwards not works. I want to mix OSS apps
with ALSA apps so everything could be played simultaniously.
Using ALSA hw:0,0 device for OSS emulation doesn't make any sense for me.

Talking about proper using mmaped mode in games, samplers and other apps
which can generate sound at any time (not exactly - precision is about
1 to several app frames) which of them could you show here?
As I know xmms mmaped mode is broken and I just don't know an app
which uses this mode with success.
I just need a good example.

Also some widely used programs have problems using native ALSA approach.
For example mplayer plays sound a bit too late (in dmix case) which
could be easily observed ("Bruce Almighty"). What is interesting playing
the same data with aoss and OSS calls we have proper A/V sync.
Mplayer's A/V status line shows perfect sync in both cases.
It's mplayers case but shows us that maybe we need a good manual
describing proper use of ALSA api. Not only what particular parameter
means but also how properly set them and how to recover from errors.
With good examples of course ;-).

> err < 0 -> error code
> err == 0 -> no action (appl_ptr was unchanged in case when you're already 
> behind hw_ptr)
OK, but in case of delay < 0 if I then do err = snd_pcm_forward(pcm, -delay)
I will get err < 0 (probably from rate plugin). So what should I do to recover
from this situaction?

> > Also what is the meaning of snd_pcm_available > alsa.buffer_size?
> You're too late, so you need to fill (or better skip via forward) some 
> more samples to synchronize appl_ptr.
Forward generates an error, so how to calculate correct appl_ptr
now and recover from error?

Regards

-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Paul Davis]

>Talking about proper using mmaped mode in games, samplers and other apps
>which can generate sound at any time (not exactly - precision is about
>1 to several app frames) which of them could you show here?
>As I know xmms mmaped mode is broken and I just don't know an app
>which uses this mode with success.
>I just need a good example.

errr, JACK? i think there are other "pro-audio" apps with ALSA
backends that use a very similar approach. JACK is full duplex, which
makes its code significantly more complex than the playback-only
engine you seem to describing.

i note, though, that JACK still does not use the ALSA provided sample
step size for interleaved access.

--p


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Tue, 7 Sep 2004, Adam Tla/lka wrote:

> On Tue, Sep 07, 2004 at 11:05:05AM +0200, Jaroslav Kysela wrote:
> > On Mon, 6 Sep 2004, Adam Tla/lka wrote:
> > There is always a drift between system and card's timing.
> ALSA appl/hw_ptr calculated position is also not exact ;-).
> If I know system time and card hw_ptr it is enough to calculate desired
> position and correct time drift. 

I don't know exactly what you want to solve. If you have another master 
timer, then you must sync with it, of course.

> > err < 0 -> error code
> > err == 0 -> no action (appl_ptr was unchanged in case when you're already 
> > behind hw_ptr)
> OK, but in case of delay < 0 if I then do err = snd_pcm_forward(pcm, -delay)
> I will get err < 0 (probably from rate plugin). So what should I do to recover
> from this situaction?
> 
> > > Also what is the meaning of snd_pcm_available > alsa.buffer_size?
> > You're too late, so you need to fill (or better skip via forward) some 
> > more samples to synchronize appl_ptr.
> Forward generates an error, so how to calculate correct appl_ptr
> now and recover from error?

The forward should work for the dmix plugin. Could you send me a little 
code which shows the error?

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Tue, Sep 07, 2004 at 03:40:04PM +0200, Jaroslav Kysela wrote:
> The forward should work for the dmix plugin. Could you send me a little 
> code which shows the error?
I must test it because after changes it doesn't shows an error.

BTW another case:

if avail = snd_pcm_available() > alsa.buffer_size then I think
that frames_to_forward = avail - alsa.buffer_size

now I do err = snd_pcm_forward(pcm, frames_to_forward)
and returned err is equal to avail

Why?
What is the correct value of frames to forward in emulated OSS buffer:
frames_to_forward or returned err value?
avail % alsa.buffer_size == (avail - alsa.buffer_size) % alsa.buffer_size
in this case which means the same ofs in ALSA ring buffer.
But OSS ring buffer size is not equal to ALSA ring buffer size
so only one value is proper for OSS appl_ptr increasing.
IMHO frames_to_forward but maybe I am wrong.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Tue, Sep 07, 2004 at 11:05:05AM +0200, Jaroslav Kysela wrote:
> We need the intelligent mmap transport for additional functionality 
> (conversions, resampling etc.). I think it's the proper way and nobody 
> (except OSS emulation) has the useability problem. You can still move 
> backwards (although it is problematic when you have a mixing on the path).
OK, that's correct if you need this for plugins in ALSA lib, but from
app point of view it should be as simple as possible. An app working in
mmapped mode should only use function which gets hw_ptr and not push any
pointers forward. If I need load huge data into an app I just fill ring
buffer with silence and just jump to load the data. Ring buffer is
running without my additional work. I could imagine that I can even
forget this step if driver has autosilense option - automatically fills
played periods with silence.
Remembering old_hw_ptr and comparing it with actual hw_ptr is all what
I need to calculate hw offset and avail of samples to update.
The ring buffer boundary should be properly set in driver
so buffer_boundary % buffer_size == 0 and then hw_ptr % buffer_size ==
hw_ofs in any case.

DMA mmaped mode:
init_mode();
old_hw_ptr = hw_ofs = 0;
avail = buffer_size;
fill_buffer();
start_playing();


update_sound() {
	hw_ptr = get_driver_hw_ptr();
	avail = hw_ptr - old_hw_ptr;
	old_hw_ptr = hw_ptr;
	appl_ofs = hw_ofs = hw_ptr % buffer_size;
	
	if (avail < 0)
		avail += buffer_boundary;
	if (avail > buffer_size)
		avail = buffer_size;
	else {
		appl_ofs -= avail;
		if (appl_ofs < 0)
			appl_ofs += buffer_size;
	}
	fill_buffer(appl_ofs, avail);
}

Clear and simple. I can modify also the data previously written in case of game
events. I think ALSA API overcomplicates the case from
application point of view.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Paul Davis]

>OK, that's correct if you need this for plugins in ALSA lib, but from
>app point of view it should be as simple as possible. An app working in
>mmapped mode should only use function which gets hw_ptr and not push any
>pointers forward. If I need load huge data into an app I just fill ring

if you don't "push pointers forward", there is no way for ALSA to
determine whether there has been an xrun. ALSA can automatically track
the h/w pointer (most of the time), but if it doesn't know how much
data the application has written (and where), it cannot compare the
two values to check for xruns.

>update_sound() {
>	hw_ptr = get_driver_hw_ptr();
>	avail = hw_ptr - old_hw_ptr;
>	old_hw_ptr = hw_ptr;
>	appl_ofs = hw_ofs = hw_ptr % buffer_size;
>	
>	if (avail < 0)
>		avail += buffer_boundary;
>	if (avail > buffer_size)
>		avail = buffer_size;
>	else {
>		appl_ofs -= avail;
>		if (appl_ofs < 0)
>			appl_ofs += buffer_size;
>	}
>	fill_buffer(appl_ofs, avail);
>}

>Clear and simple. I can modify also the data previously written in
>case of game events. I think ALSA API overcomplicates the case from
>application point of view.

the problem with this approach is that it doesn't take into account
several possibilities:

	a) there is no actual mmap-able buffer; ALSA may be providing
	     this via emulation (for certain hardware or certain kinds
	     of virtual devices), and therefore needs to know how much
	     data you actually wrote.
	b) the accessible region of the buffer may not be contiguous.
	c) the h/w pointer may have already wrapped around to the
	     start of the buffer because of scheduling delays - your code
	     will fail miserably in this case.
	d) the "previously written" data may not be physically
	     accessible - there are a few audio interfaces that
	     are not bus masters, and require the CPU to transfer
	     data to them. the "old" part of the buffer will
	     never be resent.
        e) if the PCM device is "virtual", the stride distances
	     within the buffer will vary.

The simplicity of the OSS approach is appealing, very appealing. But
it fails to handle some very important situations, and thats why
ALSA's mmap API is a bit more complex.

--p


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Thu, Sep 09, 2004 at 08:59:51AM -0400, Paul Davis wrote:
> if you don't "push pointers forward", there is no way for ALSA to
> determine whether there has been an xrun. ALSA can automatically track
> the h/w pointer (most of the time), but if it doesn't know how much
> data the application has written (and where), it cannot compare the
> two values to check for xruns.
I am talking only about mmapped ring buffer mode and it's working model
from apps point off view. Internally ALSA lib could do anything.

> the problem with this approach is that it doesn't take into account
> several possibilities:
> 
> 	a) there is no actual mmap-able buffer; ALSA may be providing
> 	     this via emulation (for certain hardware or certain kinds
> 	     of virtual devices), and therefore needs to know how much
> 	     data you actually wrote.
lib could push its internal pointers through callback functions
so even in case of virtual mmap buffer there should be no problem.

> 	b) the accessible region of the buffer may not be contiguous.
that's too bad - if I have to modify prevoiusly written part how to do
that? Ring buffer should be one part of mem. That's the idea.

> 	c) the h/w pointer may have already wrapped around to the
> 	     start of the buffer because of scheduling delays - your code
> 	     will fail miserably in this case.
In my example hw_ptr means virtual write position which is incremented
by device while playing samples so it is equal to transmitted frames
count from begin of playing. So it wraps after buffer_boundary samples
which is big enough to detect this case. But buffer_boundary is
calculated this way so hw_ptr % buffer_size always gives us hw position
in ring buffer.

> 	d) the "previously written" data may not be physically
> 	     accessible - there are a few audio interfaces that
> 	     are not bus masters, and require the CPU to transfer
> 	     data to them. the "old" part of the buffer will
> 	     never be resent.
In this case mmaped mode should be emulated.

> The simplicity of the OSS approach is appealing, very appealing. But
> it fails to handle some very important situations, and thats why
> ALSA's mmap API is a bit more complex.
So I ask about good working examples of apps using mmapped mode.
Normal music player can use just write and select to play music
because it can decode enough samples ahead. In case of games
you have small timeslice between an event in game and moment of time
when it should be heard. And we have many sound sources mixed
in realtime.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Thu, 9 Sep 2004, Adam Tla/lka wrote:

> On Tue, Sep 07, 2004 at 11:05:05AM +0200, Jaroslav Kysela wrote:
> > We need the intelligent mmap transport for additional functionality 
> > (conversions, resampling etc.). I think it's the proper way and nobody 
> > (except OSS emulation) has the useability problem. You can still move 
> > backwards (although it is problematic when you have a mixing on the path).
> OK, that's correct if you need this for plugins in ALSA lib, but from
> app point of view it should be as simple as possible. An app working in

You've not showed me a solution. Tell me about API which meets this:

1) additional processing
2) minimal overhead for direct hardware accesses
3) consistent API for everything

Actually, ALSA PCM API meets all these points.

You chose only one example (the case when the whole ring buffer should be
accessible for immediate events), and you may implement it using current 
ALSA API as:

a) I don't care, I want to use only raw hw:X,Y access, thus setup
   stream transfer without xrun checking, use mmap_begin and do ugly 
   things with the ring buffer contents ===> your code will be totaly
   unsuported by us, because you don't follow official API
b) I care about a support, but only hw:X,Y devices does matter for me --> 
   use mmap_begin/mmap_commit/avail_update/forward/rewind functions.
   Very small overhead with appl_ptr management will be added on
   the alsa-lib side in this case. The overhead is totaly negligible.
c) I care and want to be compatible with all plugins: In this case, use 
   double buffer scheme - you can have a ring buffer for immediate events 
   and use FIFO to push samples to alsa-lib using all standard functions 
   mentioned in b) - without needing to use forward and backward calls 
   which are not implemented in some cases or may add large amount of 
   unwanted processing. Of course, you will double probably the latency.

Your suggested API is like a hell. You don't know, what was changed in the
ring buffer, thus additional processing is imposible. Please, think about 
it.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Thu, Sep 09, 2004 at 05:29:20PM +0200, Jaroslav Kysela wrote:
> On Thu, 9 Sep 2004, Adam Tla/lka wrote:
> 
> > On Wed, Sep 08, 2004 at 07:15:37PM +0200, Adam Tla/lka wrote:
> > > BTW another case:
> > > 
> > > if avail = snd_pcm_available() > alsa.buffer_size then I think
> > > that frames_to_forward = avail - alsa.buffer_size
> > > 
> > > now I do err = snd_pcm_forward(pcm, frames_to_forward)
> > > and returned err is equal to avail
> > >
> > More:
> > first snd_pcm_forward results in err == 0 and next mmap_update call
> > reports bigger avail value and after snd_pcm_forward  snd_pcm_mmap_begin 
> > reports that there is no frames available to update.
> > 
> > Anyway even if I do err = snd_pcm_forward(pcm, 1) I get always 
> > err = avail or err == 0.
> > Why?
> 
> Show me the contents from snd_pcm_dump().

OK - some data below:

playback setup dump:
boundary     : 986447872
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 44100
exact rate   : 44100 (44100/1)
msbits       : 16
buffer_size  : 15052
period_size  : 940
period_time  : 21333
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 940
xfer_align   : 940
start_threshold  : 1
stop_threshold   : 15052
silence_threshold: 0
silence_size : 0
boundary     : 986447872

ioctl(6, SNDCTL_DSP_GETOPTR, 0xbffff708) -> {1085944 1 37368}
ioctl(6, SNDCTL_DSP_GETOPTR, 
AOSS: buffer_size=15052 avail=82328 forwarded=0 ERR // after snd_pcm_forward
Plug PCM: Rate conversion PCM (48000, sformat=S16_LE)
Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 44100
exact rate   : 44100 (44100/1)
msbits       : 16
buffer_size  : 15052
period_size  : 940
period_time  : 21333
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 940
xfer_align   : 1
start_threshold  : 940
stop_threshold   : 2147483647
silence_threshold: 0
silence_size : 0
boundary     : 986447872

Slave: Direct Stream Mixing PCM

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 16384
period_size  : 1024
period_time  : 21333
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 1024
xfer_align   : 1
start_threshold  : 1024
stop_threshold   : 1073741824
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Hardware PCM card 0 'Intel 82801BA-ICH2' device 0 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 16384
period_size  : 1024
period_time  : 21333
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 1024
xfer_align   : 1024
start_threshold  : 1
stop_threshold   : 1073741824
silence_threshold: 0
silence_size : 1073741824
boundary     : 1073741824
0xbffff708) -> {1415368 160 39112}

ioctl(6, SNDCTL_DSP_GETOPTR, 
AOSS: buffer_size=15052 avail=82671 forwarded=82671 // after snd_pcm_forward
Plug PCM: Rate conversion PCM (48000, sformat=S16_LE)
Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 44100
exact rate   : 44100 (44100/1)
msbits       : 16
buffer_size  : 15052
period_size  : 940
period_time  : 21333
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 940
xfer_align   : 1
start_threshold  : 940
stop_threshold   : 2147483647
silence_threshold: 0
silence_size : 0
boundary     : 986447872
Slave: Direct Stream Mixing PCM

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 16384
period_size  : 1024
period_time  : 21333
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 1024
xfer_align   : 1
start_threshold  : 1024
stop_threshold   : 1073741824
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Hardware PCM card 0 'Intel 82801BA-ICH2' device 0 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 16384
period_size  : 1024
period_time  : 21333
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 1024
xfer_align   : 1024
start_threshold  : 1
stop_threshold   : 1073741824
silence_threshold: 0
silence_size : 1073741824
boundary     : 1073741824
0xbffff708) -> {1416720 0 40464}
ioctl(6, SNDCTL_DSP_GETOPTR, 0xbffff708) -> {1419232 1 42976}
.
.
.

So as you can see I waste two ioctl's time.
First snd_pcm_forward reports err == 0 and the second one reports
err == avail and now snd_pcm_mmap_begin reports frames == 0
so I can't update the ring buffer anyway.
Third ioctl updates the ring buffer.

What is interesting snd_pcm_forward(pcm,N) always reports 0 or avail
for any N>0 in my case.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Thu, Sep 09, 2004 at 05:14:29PM +0200, Jaroslav Kysela wrote:
> You've not showed me a solution. Tell me about API which meets this:
> 
> 1) additional processing
> 2) minimal overhead for direct hardware accesses
> 3) consistent API for everything
I am telling you only about mmapped mode in which I need constantly
running ring buffer from app point of view. In other modes ALSA API
is good enough and I have no claims. Of course functions like
snd_pcm_delay or snd_pcm_avail_update have sense only in normal
read/write modes. In mmapped mode I need only to now buffer_size,
buffer_boundary and current hw_ptr. All other I can calculate by myself
and update data in place where I want. 

> 
> Actually, ALSA PCM API meets all these points.
Yes, but mmaped mode is different then it seems to be. If I just don't
use it all is perfect. I am waiting for example of good working user app
using this mode.

> 
> You chose only one example (the case when the whole ring buffer should be
> accessible for immediate events), and you may implement it using current 
> ALSA API as:
> 
> a) I don't care, I want to use only raw hw:X,Y access, thus setup
>    stream transfer without xrun checking, use mmap_begin and do ugly 
>    things with the ring buffer contents ===> your code will be totaly
>    unsuported by us, because you don't follow official API
> b) I care about a support, but only hw:X,Y devices does matter for me --> 
>    use mmap_begin/mmap_commit/avail_update/forward/rewind functions.
>    Very small overhead with appl_ptr management will be added on
>    the alsa-lib side in this case. The overhead is totaly negligible.
> c) I care and want to be compatible with all plugins: In this case, use 
>    double buffer scheme - you can have a ring buffer for immediate events 
>    and use FIFO to push samples to alsa-lib using all standard functions 
>    mentioned in b) - without needing to use forward and backward calls 
>    which are not implemented in some cases or may add large amount of 
>    unwanted processing. Of course, you will double probably the latency.
> 
> Your suggested API is like a hell. You don't know, what was changed in the
> ring buffer, thus additional processing is imposible. Please, think about 
> it.
Only the c) is valid for me but latency is important in this mode
and I must modify the ALSA ring buffer (plugin buffer).
I am not talking about ALSA lib API but only OSS emulation
which should be adequate to original OSS behaviour.
Also ALSA API should allow the same functionality then OSS
in mmapped mode (other modes are OK) or better.
Unified API for all modes means that some functionality of mmaped mode
is lost because we must push the appl_pointer forward so snd_pcm_delay
and snd_pcm_avail_update functions could be used in this mode too.
So total unification is not quite good IMHO.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Paul Davis]

>> Actually, ALSA PCM API meets all these points.
>Yes, but mmaped mode is different then it seems to be. If I just don't
>use it all is perfect. I am waiting for example of good working user app
>using this mode.

as mentioned previously, JACK uses mmap mode and supports latencies as
low as the hardware can support. it never tries to rewrite existing
data, and i believe this is the correct design. if you say you care
about latency, then you should just do what JACK does - use the ASIO
double buffered model (the app works on one half of the hardware
buffer while the hardware works on the other), and set the size of the
buffer to be small enough that you never need to rewrite
already-written data. given that we use JACK with latencies on the
order of 2-5ms, this is clearly feasible. 

i do recognize that the approach that game programmers have typically
taken has some benefits. working with large buffer sizes but then
being able to retroactively overwrite data anywhere in the buffer does
mean that realtime scheduling becomes less necessary and reduces the
CPU load associated with audio processing somewhat. if you want to do
that then jaroslav's (a) option will provide the equivalent, but it
will not be portable to non-hardware devices or hardware that doesn't
implement its hardware buffer in the way that this design
assumes. why? precisely because there really *isn't* a single
contiguous hardware buffer that works in the way that this programming
model assumes.

>Unified API for all modes means that some functionality of mmaped mode
>is lost because we must push the appl_pointer forward so snd_pcm_delay

i don't agree with this. your model of "full functionality" for mmaped
mode is based on a single conception of the hardware buffer for the
device the application is talking to. as explained by both myself and
jaroslav, ALSA supports devices where this conception is invalid. if
you want to work with such devices, you have to modify your conception
of what the hardware buffer is and how it works, and thats precisely
what mmap_begin/commit/avail_update/forward/rewind are there to assist
with.

--p


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Fri, Sep 10, 2004 at 07:44:55AM -0400, Paul Davis wrote:
> as mentioned previously, JACK uses mmap mode and supports latencies as
> low as the hardware can support. it never tries to rewrite existing
> data, and i believe this is the correct design. if you say you care
> about latency, then you should just do what JACK does - use the ASIO
> double buffered model (the app works on one half of the hardware
> buffer while the hardware works on the other), and set the size of the
> buffer to be small enough that you never need to rewrite
> already-written data. given that we use JACK with latencies on the
> order of 2-5ms, this is clearly feasible. 
Nice but jack is not a normal user land app. It's a sound daemon program
with suid or working with specially patched kernel so it have set
realtime scheduler and memory locked so it colud not be swapped out.
Are you saying that a game should meet this requirements to generate
proper sound in mmapped mode? It is not an advantage of the API.

> 
> i do recognize that the approach that game programmers have typically
> taken has some benefits. working with large buffer sizes but then
> being able to retroactively overwrite data anywhere in the buffer does
> mean that realtime scheduling becomes less necessary and reduces the
> CPU load associated with audio processing somewhat.
Yes and with ALSA API approach this functionality is lost. I just can
say that mmaped ALSA mode is not any better then normal read/write mode.
Only difference is that we need not copy the sound data from our buffer
to device buffer. We writting it directly to device - theoretically,
because if there are plugins in the path some copying will be done.
But it is hidden inside the ALSA lib so an app thinks that is is
writting data directly. So we only omit one copying and writting data to
first plugin buffer on the path. That's only difference.

> that then jaroslav's (a) option will provide the equivalent, but it
a) option is not my option because I want many simultaniously working
sound apps. Only c) ;-)

> will not be portable to non-hardware devices or hardware that doesn't
> implement its hardware buffer in the way that this design
> assumes. why? precisely because there really *isn't* a single
> contiguous hardware buffer that works in the way that this programming
> model assumes.
OK, I understand that.

> 
> 
> i don't agree with this. your model of "full functionality" for mmaped
> mode is based on a single conception of the hardware buffer for the
> device the application is talking to. as explained by both myself and
> jaroslav, ALSA supports devices where this conception is invalid. if
> you want to work with such devices, you have to modify your conception
> of what the hardware buffer is and how it works, and thats precisely
> what mmap_begin/commit/avail_update/forward/rewind are there to assist
> with.
Yes that's correct. I want support above but in OSS emulation behave
as it have automatically running continous buffer in memory mmapped
mode. I allocate the buffer in AOSS lib so it is one chunk of mem.
It's size is not always same as ALSA buffer size because OSS has some
restrictions buffer_size == 2^N (so oss_buffer >= alsa_buffer).
Also OSS locks buffer size after some ioctls while ALSA could still 
change its buffer size (OSS buffer size should be big enough at the start).
Actually it works quite good but sometimes sound is distorted and ALSA
does not report any errors. I have also small problems with
snd_pcm_forward. It reports 0 or value previusly reported by
snd_pcm_avail_update call not depending on requested frames to forward.
Also with current AOSS approach data is transfered only while an app is
doing sound ioctl. In other case we have buffer underrun.
Maybe I should use callback to transfer data from one buffer to another?

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Paul Davis]

  [ JACK ]

>Nice but jack is not a normal user land app. It's a sound daemon program
>with suid or working with specially patched kernel so it have set
>realtime scheduler and memory locked so it colud not be swapped out.
>Are you saying that a game should meet this requirements to generate
>proper sound in mmapped mode? It is not an advantage of the API.

realtime programming is realtime programming. either you use a
programming approach that doesn't require realtime (which is what the
"overwrite the older part of the hardware buffer" is all about), or
you have to follow the requirements for RT, which include
SCHED_FIFO/RR scheduling and locking all memory.

and anyway, what JACK does is not at all unusual. its code was taken
from within an older implementation of ardour, and currently ecasound
and others do something very very similar.

>> i do recognize that the approach that game programmers have typically
>> taken has some benefits. working with large buffer sizes but then
>> being able to retroactively overwrite data anywhere in the buffer does
>> mean that realtime scheduling becomes less necessary and reduces the
>> CPU load associated with audio processing somewhat.
>Yes and with ALSA API approach this functionality is lost. I just can

For the third time, it is *NOT* lost. What is lost is the ability to
pretend that the h/w buffer is just a single contiguous chunk of
physical RAM that is always accessible to the application. As Jaroslav
and I have explained, you don't need to use the ALSA API "extras" for
mmap mode. The cost of not doing so is that you lose the ability to
get xrun detection, just as in OSS.

>> will not be portable to non-hardware devices or hardware that doesn't
>> implement its hardware buffer in the way that this design
>> assumes. why? precisely because there really *isn't* a single
>> contiguous hardware buffer that works in the way that this programming
>> model assumes.
>OK, I understand that.

then why keep pushing for a (c)-style solution (i.e. compatible with
all possible ALSA devices), when you clearly want either (a) or (b)?

>> i don't agree with this. your model of "full functionality" for mmaped
>> mode is based on a single conception of the hardware buffer for the
>> device the application is talking to. as explained by both myself and
>> jaroslav, ALSA supports devices where this conception is invalid. if
>> you want to work with such devices, you have to modify your conception
>> of what the hardware buffer is and how it works, and thats precisely
>> what mmap_begin/commit/avail_update/forward/rewind are there to assist
>> with.
>Yes that's correct. I want support above but in OSS emulation behave
>as it have automatically running continous buffer in memory mmapped
>mode. I allocate the buffer in AOSS lib so it is one chunk of mem.

no, you don't allocate the real buffer at all. 

AFAICT, the key functionality that you require is the ability to
overwrite parts of the buffer that are outside the range of the
current "period". but the buffer in question is not one allocated by
libaoss or any other userspace software. it may not even be
"allocated" by the kernel because it may correspond to memory
physically located on the audio interface. 

there are audio interfaces (the RME/Marion PAD series come to mind, as
well as any non-busmaster devices) that will not let even the kernel
access the full range of the buffer at arbitrary times. your design
model can't handle these.

so once again, the first question that you need to answer in an
unambiguous way is: do i want my code to support any and all ALSA PCM
devices, or just some specific subset of them? if the latter, which
specific subset?

if you decide you don't want this "overwrite data previously written"
functionality, then there is nothing in the existing ALSA API that
will cause you any problems. if you believe that the kernel will never
screw up scheduling, ignore snd_pcm_avail() and go with your
assumptions. if you don't care about xrun detection, ignore
snd_pcm_forward() and it should work fine.

--p


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tla/lka]

On Mon, Sep 13, 2004 at 09:05:56AM -0400, Paul Davis wrote:
>   [ JACK ]
> realtime programming is realtime programming. either you use a
> programming approach that doesn't require realtime (which is what the
> "overwrite the older part of the hardware buffer" is all about), or
> you have to follow the requirements for RT, which include
> SCHED_FIFO/RR scheduling and locking all memory.
> 
> and anyway, what JACK does is not at all unusual. its code was taken
> from within an older implementation of ardour, and currently ecasound
> and others do something very very similar.
Those are rather specialized sound apps. But I take a look at them.

> For the third time, it is *NOT* lost. What is lost is the ability to
> pretend that the h/w buffer is just a single contiguous chunk of
> physical RAM that is always accessible to the application. As Jaroslav
> and I have explained, you don't need to use the ALSA API "extras" for
> mmap mode. The cost of not doing so is that you lose the ability to
> get xrun detection, just as in OSS.
If I am not using snd_pcm_mmap_begin and snd_pcm_mmap_commit I can't
get ALSA buffer address and pointer so I can't also properly fill it.
So how do you suggest I should use mmapped mode without using this API?
 
> then why keep pushing for a (c)-style solution (i.e. compatible with
> all possible ALSA devices), when you clearly want either (a) or (b)?
I am using dmix plugin with card which has not hardware mixing.

> >mode. I allocate the buffer in AOSS lib so it is one chunk of mem.
> 
> no, you don't allocate the real buffer at all. 
look at pcm.c:1344 in alsa-oss/alsa:
 assert(!str->mmap_buffer);
 result = malloc(len);
OSS simulated ring buffer is allocated here ;-).

> AFAICT, the key functionality that you require is the ability to
> overwrite parts of the buffer that are outside the range of the
> current "period". but the buffer in question is not one allocated by
> libaoss or any other userspace software. it may not even be
> "allocated" by the kernel because it may correspond to memory
> physically located on the audio interface. 
OK.

> if you decide you don't want this "overwrite data previously written"
> functionality, then there is nothing in the existing ALSA API that
> will cause you any problems. if you believe that the kernel will never
> screw up scheduling, ignore snd_pcm_avail() and go with your
> assumptions. if you don't care about xrun detection, ignore
> snd_pcm_forward() and it should work fine.
requested feature should work from OSS aps point of view but of course
will not really exist in ALSA implementation. So I must have as small
period size as possible on ALSA size. The app_ptr should be pushed by
calback fuction. Of course this is not an ideal soultion but if period
size will be small enough we should have proper sound.

Generally speaking ALSA AOSS lib is a partial solution. It doesn't
emulate all needed features of OSS and doesn't work with all apps -
statically compiled and disabling LD_PRELOAD variable.
LD_PRELOAD variable usage is a security violation IMHO.
Also poll/select call is not working fast enough for some apps
(those using SDL for example).

So there should be a kernel module which emulates OSS /dev calls
and routes them to some sound daemon using RT sched and memory locking
to do accurate mixing and other special sound processing.
An OSS app should not even know about these all so simple
cat file.wav > /dev/dsp will work properly.
Also proprietary apps with closed code will work properly.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

[2004-09-13 15:05] Paul Davis:
> ...What is lost is the ability to
> pretend that the h/w buffer is just a single contiguous chunk of
> physical RAM that is always accessible to the application. As Jaroslav
> and I have explained, you don't need to use the ALSA API "extras" for
> mmap mode. The cost of not doing so is that you lose the ability to
> get xrun detection, just as in OSS.
First of all in OSS GETOPTR call returns hw_ptr and number of bytes 
processed by device so xrun detection is not a problem! The number of 
bytes value wraps after about an hour but this is not the case.
Comparing previous values with the obtained one xrun detection is easy.
You can even use a GETODELAY call if you don't want to calculate it.
So your arguments about OSS are just not true.

>>>will not be portable to non-hardware devices or hardware that doesn't
>>>implement its hardware buffer in the way that this design
>>>assumes. why? precisely because there really *isn't* a single
>>>contiguous hardware buffer that works in the way that this programming
>>>model assumes.
OK but we could simply emulate this in a kernel driver with continous 
memory buffer and copying from it to real hw device period by period.
We could modify data which is not sent to the hw device. Latency could 
be as small as 1-1.5 of period size. With small enough periods it could 
be a quite nice solution. It should be in kernel to obtain proper 
scheduling and memory locking. An app using this approach may be a 
normal app because it could modify data with a few samples after current
playing position (minimal delay is one period) and write big chunks of data.

Current in lib mixing means that all this kind of apps needs root 
priviledges or specially patched kernel and capabilities to obtain RT 
scheduling and memory locking - they should be specially written.
So this is rather a disadvantage and probaly a security risk to promote 
this kind of solution as a better then OSS future design.
Also old or proprietary closed source apps will never work correctly 
using this approach under big system load or when switching big apps
- rescheduling and swapping effects will broke sound stream processing 
and will make cracling and noises.

> there are audio interfaces (the RME/Marion PAD series come to mind, as
> well as any non-busmaster devices) that will not let even the kernel
> access the full range of the buffer at arbitrary times. your design
> model can't handle these.
As I wrote before it could be simulated by sending small periods of
data to the real device. If the device could use continous DMA buffer 
then use it and if not then emulate this behaviour.

> if you decide you don't want this "overwrite data previously written"
> functionality, then there is nothing in the existing ALSA API that
> will cause you any problems. if you believe that the kernel will never
> screw up scheduling, ignore snd_pcm_avail() and go with your
> assumptions. if you don't care about xrun detection, ignore
> snd_pcm_forward() and it should work fine.
I need this functionality and xrun detection too. This is a multiuser, 
multitasking system so I can't assume that schedulling is always
on time. Generally nobody can assume this.

Regards

-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Paul Davis]

>First of all in OSS GETOPTR call returns hw_ptr and number of bytes 
>processed by device so xrun detection is not a problem! The number of 
>bytes value wraps after about an hour but this is not the case.

no, thats not the type of wrapping that matters. suppose the h/w
buffer is 4096 frames in size. suppose that a rogue PCI driver or
device prevents receipt of an interrupt for an entire buffer's worth
of time, maybe even longer. looking at the value of the h/w ptr by
itself doesn't tell you anything about whether there is an xrun. you
have to constantly monitor the *expected* time of the next interrupt
along with the *expected* position of the h/w ptr in order to
establish if there was an xrun or not (at least for the class of xruns
caused by this kind of delay).

>Comparing previous values with the obtained one xrun detection is easy.
>You can even use a GETODELAY call if you don't want to calculate it.
>So your arguments about OSS are just not true.

user-space is not in a position to determine this, because the
interrupt handler is the only place where the value of the h/w ptr can
be reliably determined (even though on many cards, there are other
ways and times as well).

>OK but we could simply emulate this in a kernel driver with continous 
>memory buffer and copying from it to real hw device period by period.
>We could modify data which is not sent to the hw device. Latency could 
>be as small as 1-1.5 of period size. With small enough periods it could 
>be a quite nice solution. It should be in kernel to obtain proper 
>scheduling and memory locking. An app using this approach may be a 
>normal app because it could modify data with a few samples after current
>playing position (minimal delay is one period) and write big chunks of data.

ALSA and the entire kernel development team have spent the last 5
years moving things *out* of kernel space. forget ALSA - you will have
a very, very hard time explaining to the kernel crew why this is
actually a good idea.

moreover, you are completely forgetting that the non-hw PCM devices
that i've mentioned where this "contiguous buffer" doesn't necessarily
exist are *in user space*. the kernel knows nothing about them.

>Also old or proprietary closed source apps will never work correctly 
>using this approach under big system load or when switching big apps
>- rescheduling and swapping effects will broke sound stream processing 
>and will make cracling and noises.

this is entirely orthogonal.

>> if you decide you don't want this "overwrite data previously written"
>> functionality, then there is nothing in the existing ALSA API that
>> will cause you any problems. if you believe that the kernel will never
>> screw up scheduling, ignore snd_pcm_avail() and go with your
>> assumptions. if you don't care about xrun detection, ignore
>> snd_pcm_forward() and it should work fine.
>I need this functionality and xrun detection too. This is a multiuser, 
>multitasking system so I can't assume that schedulling is always
>on time. Generally nobody can assume this.

but you haven't offered any information about what you propose to do
with the fact that scheduling may go wrong or that an xrun may
happen. the information that ALSA provides appears completely useless
to you. it seems to me that all you want to know is the delta between
the hw ptr and the appl ptr, plus the ability to write "behind" the
appl ptr.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

> no, thats not the type of wrapping that matters. suppose the h/w
> buffer is 4096 frames in size. suppose that a rogue PCI driver or
> device prevents receipt of an interrupt for an entire buffer's worth
> of time, maybe even longer. looking at the value of the h/w ptr by
> itself doesn't tell you anything about whether there is an xrun. you
> have to constantly monitor the *expected* time of the next interrupt
> along with the *expected* position of the h/w ptr in order to
> establish if there was an xrun or not (at least for the class of xruns
> caused by this kind of delay).
NO NO NO - look at the OSS man page. GETOPTR call returns also bytes 
value which represents a number of bytes processed since opening the 
device. So I can easily detect xruns just by comparing two returned
bytes values - a previous and a current one. There is also a blocks 
value which represents number of fragments transitions (hw periods 
transfers) since the previous call to this ioctl - reset to 0 after each 
call. I am not monitoring hw-ptr difference but count of data processed 
be a device. I need hw-ptr only for correct mixing of data but not for 
xrun detection. Anyway if some hw device blocks hw handler of a sound 
card you will not detect xruns without counting interuppts and their 
time in the device driver. This situaction means badly designed system 
or hardware.

> user-space is not in a position to determine this, because the
> interrupt handler is the only place where the value of the h/w ptr can
> be reliably determined (even though on many cards, there are other
> ways and times as well).
I just need to obtain hw_ptr from a device driver in mmapped mode.
If there is a ioctl getting it that is good thing IMHO. In ALSA I must 
maintain my appl_ptr and call snd_pcm_delay or snd_pcm_avail_update and 
then calculate hw_ptr by myself. Of course I must be aware of boundary 
wrap to obtain the correct result.

> ALSA and the entire kernel development team have spent the last 5
> years moving things *out* of kernel space. forget ALSA - you will have
> a very, very hard time explaining to the kernel crew why this is
> actually a good idea.
Hmm, actually from my observation this approach (in lib mixing and 
effects) makes more problems and disadventages then doing this in a 
device manner and as a kernel RT thread. I tried to modify AOSS to use 
callbacks (works almost good but scheduling/swapping effects still 
there) but I found an app which disables SIGIO for example.
So now I in a dead end. I think that ALSA lib approach has serious 
compability limitations which could not be solved.

Regards

-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Mon, 27 Sep 2004, Adam Tlałka wrote:

> > ALSA and the entire kernel development team have spent the last 5
> > years moving things *out* of kernel space. forget ALSA - you will have
> > a very, very hard time explaining to the kernel crew why this is
> > actually a good idea.
> Hmm, actually from my observation this approach (in lib mixing and 
> effects) makes more problems and disadventages then doing this in a 
> device manner and as a kernel RT thread. I tried to modify AOSS to use 
> callbacks (works almost good but scheduling/swapping effects still 
> there)

Are you using fully loaded ring buffer on the ALSA side with a decent 
size?

> but I found an app which disables SIGIO for example.

It might be solved with the loopback device and a RT mixing daemon.

> So now I in a dead end. I think that ALSA lib approach has serious 
> compability limitations which could not be solved.

I don't think that it's something which cannot be solved.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Paul Davis]

>> no, thats not the type of wrapping that matters. suppose the h/w
>> buffer is 4096 frames in size. suppose that a rogue PCI driver or
>> device prevents receipt of an interrupt for an entire buffer's worth
>> of time, maybe even longer. looking at the value of the h/w ptr by
>> itself doesn't tell you anything about whether there is an xrun. you
>> have to constantly monitor the *expected* time of the next interrupt
>> along with the *expected* position of the h/w ptr in order to
>> establish if there was an xrun or not (at least for the class of xruns
>> caused by this kind of delay).
>NO NO NO - look at the OSS man page. GETOPTR call returns also bytes 
>value which represents a number of bytes processed since opening the 
>device. So I can easily detect xruns just by comparing two returned
>bytes values - a previous and a current one. There is also a blocks 
>value which represents number of fragments transitions (hw periods 
>transfers) since the previous call to this ioctl - reset to 0 after each 
>call. I am not monitoring hw-ptr difference but count of data processed 
>be a device. 

you're simply wrong about this. if an interrupt is blocked for longer
than the buffer size, GETOPTR can't help you.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

 >>I tried to modify AOSS to use
>>callbacks (works almost good but scheduling/swapping effects still 
>>there)
> Are you using fully loaded ring buffer on the ALSA side with a decent 
> size?
No because of low latency mixing requirements. Buffer is filled with two 
periods of data at the beginning and the callback refills it to maintain 
delay to be about this size.

>>but I found an app which disables SIGIO for example.
> It might be solved with the loopback device and a RT mixing daemon.
But now? Just ,,Enjoy The Silence''.

> I don't think that it's something which cannot be solved.
Maybe, but clock is ticking, compability is broken
and MS Windows system still is a better solution
in sound area. I personally want to offer Linux solution as a desktop 
multimedia system but at this time I just can't.
Sorry to say that.

Evolution is what is going in the nature. From my point of view (and 
many others for sure) I don't need a new API. I just need better 
functionality and some additional features expanding existing API.

OK. If you don't want mixing in kernel space doing this and other 
effects in some special RT daemon looks like step in right direction.
If an app could comunicate with it through /dev interface it could be 
unchanged and compability will be saved.

Regards

-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

> you're simply wrong about this. if an interrupt is blocked for longer
> than the buffer size, GETOPTR can't help you.
So how is ALSA doing this if its hw handler is not callet at proper 
time? How snd_pcm_delay is working if no hw_ptr nor appl_ptr is moved?

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

>>>you're simply wrong about this. if an interrupt is blocked for longer
>>>than the buffer size, GETOPTR can't help you.
>>
>>It depends of kernel driver behaviour. If it could not detect this 
>>situaction then of course no. But this is easy to detect just by 
>>monitoring actual system time and amount of data send to/received from 
>>device. We know what should be the proper value.
>>Anyway if this situaction occurs how ALSA driver detects it?
>>hw_ptr is not moved and appl_ptr too so how ALSA is doing that?
> 
> thats my whole point. the facilities offered by OSS to track this
> stuff all presuppose that this kind of disaster can't happen, but it
> *does* happen. ALSA obviously cannot do any better in that situation,
> but it has an infrastructure in place that doesn't make the assumption
> that things just work. It would be easy to get ALSA to indicate an
> xrun in the above situation; it would be quite hard to get OSS to do
> so.

So ALSA is not any better in that situaction ;-(. Talking about OSS
if we modify the driver so it detects hardware xruns it can report them
in a same manner as software ones. For example GETOPTR bytes value 
should return count of bytes which would be processed by a device
if there was no xrun. hw_ptr will be unchanged. So we can correct our 
sample position because we know the delay and the hw_ptr.
I think that the problem is not in the API but in the kernel driver.
It should detect this situaction - both ALSA and OSS driver.


> anyway, we're way off topic here. the essential issue is that you want
> an API that allows for large buffers but also lets you overwrite stuff
> you have written in the past, in order to offer the illusion of low
> latency without impacting CPU load too much. by contrast, the
> pro-audio/music world wants small buffer sizes to reduce latency
> because we do everything in real time. the consumer audio world wants
> virtual devices with various specific capabilities that hide the
> complexity of the underlying hardware. the kernel developers don't
> want emulators, sample rate converters and so on in the kernel.
Yes and almost all of this problems could be solved by mixing
this kernel/userspace approach. A kernel module emulating /dev access
and ioctl's communicating with RT daemon which is doing real job
and contacting with physical device.

/dev access is needed for compability and access granting (chmod and 
ACL's) and also simple cat file.wav > /dev/dsp possibilities,
OSS apps also need that

more sophisticated apps can talk directly to the daemon and through it
to the hw device


> 
> in the windows world, the two outlined goals are viewed as orthogonal,
> and nobody uses the same audio driver API to achieve them. that maybe
> changing with WDM, but at least until recently, the pro-audio world
> focused on ASIO which no games use; games used directX, which almost
> no audio apps did.
Linux is not only for pro-audio world I think. And placeing something in 
kernel (ALSA drivers I mean) should not break existing normal apps.

> and anyway, i am not really sure what you want. ALSA lets you do what
> you want but at the cost of having to make a few more function calls
> to cover the handling of virtual devices. you don't like the cost,
current ALSA could not meet my requirements because of 
swapping/scheduling effects which makes distorted sound in normal non RT 
apps. Doing just a few more calls doesn't help in this case ;-[.

> you'd rather move the cost so that its in the
> kernel or a library rather than be in your code. that's the best i can
> understand so far.
Yes - that's the point. Common operations like format changeing, 
resampling, remixing and additional effects should be done
in one place not in every app by itself.
I want to have possibility of doing cat file.wav > /dev/dsp
and play it with 5.1 or 2 speakers or with headphones with special 
stereo  effects applied just by one click or keypress on special mixer 
app on the fly without restarting anything and fiddling with config 
files and program execution arguments.
Current ALSA design is not user friendly and rather not meets these end 
user requirements. May be it should be only for audio profs?

Regards

-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Paul Davis]

>in sound area. I personally want to offer Linux solution as a desktop 
>multimedia system but at this time I just can't.
>Sorry to say that.

this is getting really irritating adam. you *can* do this, i *do* it.
you don't like the API and you want to be able to overwrite any part
of the buffer. this is not equivalent to "offering linux as a desktop
multimedia system.

>If an app could comunicate with it through /dev interface it could be 
>unchanged and compability will be saved.

ah, so thats the essence here. you still want apps to use the OSS API.
ok, i'm out of here.

--p


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Jaroslav Kysela]

On Tue, 28 Sep 2004, Adam Tlałka wrote:

> And placeing something in kernel (ALSA drivers I mean) should not break
> existing normal apps.

We don't break normal apps. You're referring mostly to commercial product 
(OSS/Unix). The OSS code in Linux kernel does not offer functionality you 
requested, too.

> I want to have possibility of doing cat file.wav > /dev/dsp
> and play it with 5.1 or 2 speakers or with headphones with special 
> stereo  effects applied just by one click or keypress on special mixer 
> app on the fly without restarting anything and fiddling with config 
> files and program execution arguments.
> Current ALSA design is not user friendly and rather not meets these end 
> user requirements. May be it should be only for audio profs?

Help us. I have all those ideas in my brain, but they are not implemented 
due lack of time. Crying - that something is not implemented - will not 
help us at all.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Paul Davis]

>current ALSA could not meet my requirements because of 
>swapping/scheduling effects which makes distorted sound in normal non RT 
>apps. Doing just a few more calls doesn't help in this case ;-[.

oh c'mon. thats not ALSA. the *kernel* can't meet your
requirements. ALSA has nothing to do with it. OSS apps and drivers
can't change the way the kernel schedules tasks. the same broken
device drivers will coexist with any kernel-side API that you
propose. you're mistaking where these issues exist.

>> you'd rather move the cost so that its in the
>> kernel or a library rather than be in your code. that's the best i can
>> understand so far.
>Yes - that's the point. Common operations like format changeing, 
>resampling, remixing and additional effects should be done
>in one place not in every app by itself.

  ***   -lasound  ****

>I want to have possibility of doing cat file.wav > /dev/dsp
>and play it with 5.1 or 2 speakers or with headphones with special 

and you want this to work with no clicks or pops? and it will, i'm
guessing, because you think that /dev/dsp is somehow going to
magically know that it should use the maximum size buffer when used
with no parameters?

>stereo  effects applied just by one click or keypress on special mixer 
>app on the fly without restarting anything and fiddling with config 

special mixer app eh? for which audio interface? who wrote it? does it
work with my foobar GH8782 audio chipset?

>files and program execution arguments.
>Current ALSA design is not user friendly and rather not meets these end 
>user requirements. May be it should be only for audio profs?

ALSA is not particularly friendly for audio profs. its not
particularly friendly to *anyone*. but that is a completely different
issue than the design of the API.

--p


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Takashi Iwai]

At Tue, 28 Sep 2004 10:57:26 -0400,
Paul Davis wrote:
> 
> >current ALSA could not meet my requirements because of 
> >swapping/scheduling effects which makes distorted sound in normal non RT 
> >apps. Doing just a few more calls doesn't help in this case ;-[.
> 
> oh c'mon. thats not ALSA. the *kernel* can't meet your
> requirements. ALSA has nothing to do with it. OSS apps and drivers
> can't change the way the kernel schedules tasks. the same broken
> device drivers will coexist with any kernel-side API that you
> propose. you're mistaking where these issues exist.

I agree with Paul.  It's the kernel issue.  For example, with the Con
Kolivas's patch, you can choose another scheduler class which works
much better in such a situation (it's a kind of safe soft-RT w/o root
priv).

However, having a functionality to creata a kernel-thread (with a
slightly higher priority) for the large intermediate buffer handling
sounds not too difficult.  It might be even a good idea - at least,
all opererations can be transparent.

This will offer the more stable playback but of course much worse
audio control.  But it will surely make the life of some people easier
:)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

>>in sound area. I personally want to offer Linux solution as a desktop 
>>multimedia system but at this time I just can't.
>>Sorry to say that.
> 
> 
> this is getting really irritating adam. you *can* do this, i *do* it.
> you don't like the API and you want to be able to overwrite any part
> of the buffer. this is not equivalent to "offering linux as a desktop
> multimedia system.
 From my point of view it is. I have some closed source multimedia apps
which need properly working OSS interface - java, flash player, real 
player,games and some others. You are using jack which is another 
approach requiring *rewritting* of apps. I *cannot* do this.

>>If an app could comunicate with it through /dev interface it could be 
>>unchanged and compability will be saved.
> 
> 
> ah, so thats the essence here. you still want apps to use the OSS API.
> ok, i'm out of here.
Yes, I need OSS api. It is not the problem with api. The OSS api fits my 
needs. OSS doesn't detect hw xruns but ALSA is not doing that too.
So problem is in implementing better functionality of the drivers
without changeing api. Commercial OSS is doing it that way and that is 
the proper way I think. So improving OSS/Free and expanding its 
functionality and adding new ioctl's if needed is a better way then 
makeing a completly new api. There could be a module layer on top of 
ALSA hw drivers doing that. We could do advanced functions in kernel or 
in RT daemon but from api point of view there should be no change.
Some kernel work should be done too, because kernel should know that 
some types of devices are multimedia ones (audio, video or some RT data 
grabbers and specialized devices) which should be treated specially.
Without kernel support it always will work poorly. So extracting this 
all from kernel is not a good way too.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Re: [Alsa-user] AD1985 full-duplex(?)

[Adam Tlałka]

> oh c'mon. thats not ALSA. the *kernel* can't meet your
> requirements. ALSA has nothing to do with it. OSS apps and drivers
> can't change the way the kernel schedules tasks. the same broken
> device drivers will coexist with any kernel-side API that you
> propose. you're mistaking where these issues exist.
The problem is that we have a new api and same problems as in old OSS 
api case. So we should improve drivers and their functionality - xrun 
detection and some additional features without changeing the api.
As you said it's not the api problem so why change it?
Broken compability, non working closed source apps or non portable 
between different operating systems that is the price of api change.
But do we have better functionality? Only a bit and old problems remain.

>>Yes - that's the point. Common operations like format changeing, 
>>resampling, remixing and additional effects should be done
>>in one place not in every app by itself.
>   ***   -lasound  ****
a program lib functions are working in this program context so without 
special RT program design we will always end up with bad sound effects.

>>I want to have possibility of doing cat file.wav > /dev/dsp
>>and play it with 5.1 or 2 speakers or with headphones with special 
> and you want this to work with no clicks or pops? and it will, i'm
> guessing, because you think that /dev/dsp is somehow going to
> magically know that it should use the maximum size buffer when used
> with no parameters?
It is the driver implementation - I think buffer should be large but 
period as small as possible. Swithing modes will not work without some
sound effects but we could mute the sound for the moment. And if done in 
kernel or RT daemon it should be fast enough. Anyway you are not doing 
that every second or so.

>>stereo  effects applied just by one click or keypress on special mixer 
>>app on the fly without restarting anything and fiddling with config 
> special mixer app eh? for which audio interface? who wrote it? does it
> work with my foobar GH8782 audio chipset?
Probably you should write it or someone who has access to doc and hw 
device. It should be an extension plugin for the RT audio daemon which 
provides additional funtionality.

> ALSA is not particularly friendly for audio profs. its not
> particularly friendly to *anyone*. but that is a completely different
> issue than the design of the API.
True so we don't need a new one.

Regards
-- 
Adam Tla/lka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdansk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl