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(?)

[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(?)

[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(?)

[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(?)

[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ł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(?)

[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, 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