WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Montag, 17. November 2003 22:58 schrieb James Courtier-Dutton:
> Hi,
>
> Just a general comment on dmix/dsnoop.
> 1) It is not bug free yet.
right. It would be great if you guys that have some overview would map out
some basic "TODO" - where all outstanding bugs and all missfeatures that need
fixing would be listed. That way progress could be monitored, and people that
would want to help on this task would quickly see what there is to do.
> 2) For smart dmix/dsnoop to be really user friendly, we will need a
> version of it that works in full duplex. I.E. Multiple applications able
> to record the same stream as well as play to it at the same time.
Well,
what I gathered from talking to people, dmix is for playback and dsnoop is for
capture. Thats why I suggest to implement this using those two
plugins...because I thought this would give us full duplex. So yes, full
duplex support for as many application as the user wishes is definetly
something that my feature suggestion should achieve when implemented.
> 3) If one application wishes to play to "surround51" and a different
> application wishes to play to "front", dmix will have to be clever
> enought to mix the two.
correct.
> 4) If one application wishes to play to "front" and a different
> application wishes to play to "rear", the mixer should be able to mix to
> get 4 output channels.
agreed.
> 5) I think that this sound mixing problem might be better served by
> sound servers like jack.
Hmmm,
actualy I did have a very close look at jack, but the problem that I saw
(correct me if Im wrong here), is the fact that jack only works well if the
applications are specificaly geard to work with it. To quote the FAQ:
#How can I make my app use Jack?
#Your app must be callback-based. This means that you shouldn't block on
#writes or reads from a PCM device; rather, you should have your app be
#"driven" by a function that gets called at regular intervals. This is a
#design decision. Then, take a look at the simple client code, and do your
#interesting stuff inside the process() function.
#Note that code written for any callback API can generally be ported to any
#other callback API fairly easily. Code that is written around a "blocking I/
#O" model generally needs to completely redesigned to be used in any kind of
#callback API.
Because of this I tossed the idea of using jack for this asside - and found
dmix/dnsoop. Now you might say: Its open source, just wait until all the
applications are adapted to use jack. But, even if everybody would be
convinced of the necessity - it would take a long time. Also one of my main
interests for this whole mixing thing is voice-communication alongside with
games. And you might know that (closed source) games like quake3, unreal
tournament 2003 etc. will just NOT get any special jack support in it
anymore, especially since theyd needed to be "completly redesigned".
> 6) software mixing is ok, but software resampling is not a good idea to
> do in alsa-lib, because a) It cannot do good quality resamplings because
> t is trying to keep latency low. b) A audio/video application could do
> resampling better because it could do it at the decoding stages, before
> latency and audio/video sync is a problem.
Ok, Im not the guy that knows about the workings of alsa-driver, but I guess
currently a application like xine *knows* what sample rate the soundcards
supports, and then gives alsa-lib a soundstream that is sampled to that
specific rate ? If this would be the case, then nothing would change if smart
dmix/dnsoop would be implemented. If the only playback stream is already
taken, with sample rate "X", then alsa-lib would tell xine, that the
soundcard [currently] only supports sample rate "X" in hardware - and xine
would do the resampling to "X". Only if a application that doesnt care to
investigate what samplerates are supported just sends sound to alsa-lib, in
sample rate "Y", then resampling would have to be done.
If I understand it correctly, then current alsa-lib will resample if
necessary. To quote the .asoundrc wiki:
#Which automatically converts your samples to a 44.1 kHz sample rate while
#playing. It's not very useful because most players and alsa converts samples
#to the right sample rate which your soundcard is capable of, but you can use
#it for a conversion to a lower static sample rate for example.
There would be no change in this behavior, except that it might be necessary
more often (in the cases where alsa-lib currently says "no way stream,
soundcard is full").
> 7) For mixing, each open of the alsa multi-open device should have it's
> own volume control per open, and not just the hardware backend volume
> controls. The application could easily control their own volume, without
> effecting other application's volume.
This extends my feature suggestion, but its IMHO a great idea. If this is
possible and viable, go for it too =).
> Summary: -
> An application should be able to use device names like "rear", "front",
> "surround51" and then have a separate control to tell alsa whether it is
> allowed to do resampling or not. Then at least the more advanced
> application could decide for itself whether to use alsa-lib's low
> quality resampler, or implement it's own multi-tap interpolation filter.
> For a video/audio application like xine.sf.net, being able to open the
> alsa device in such a way to ensure we know where the sound will be
> routed(which speakers sound will come from) is useful.
sounds right. I realy hope you guys can do this.
Peter
- --
Everyone wants results, but no one is willing to do what it takes to get them.
-- Dirty Harry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/ubNvg2ieGvTmHiURAmt0AJ4suWE18CpAVTd0bWwwJw6qYN9KiwCfbKoD
JUquoVkakeAfLrm26zVff78=
=Fn3b
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
