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

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

> 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