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

["Adam Tlałka" <atlka@pg.gda.pl>]

[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