I'm about to release Pd 0.30, in a day or so I hope, just to warn everyone...
I will send you something today or tomorrow, then. Even if it is just basic ALSA support it would be nice for it to be in the new release. As the ALSA developers finish their documentation and work out the details of their more advanced features they can be added.
I don't think OSS's interleaving scheme is necessarily advantageous over any other scheme that you could propose. Perhaps there's a much better one...? Perhaps ALSA will even find one and incorporate it for their multichannel support. cheers Miller
I just meant the way the oss_send_dacs function stuffs the sys_soundout into the output buffer or vice-versa for sys_soundin. Alsa does have provisions for writing non-interleaved (vector) data to cards through their library. Some cards (Hammerfall is one I believe) don't want interleaved data so using their library prevents duplication of work (deinterleaving samples for cards that don't want it). As I mentioned, the details of this aren't clear at the moment because of a lack of documentation.
Karl
On Sat, Mar 04, 2000 at 05:43:10PM -0500, Karl MacMillan wrote:
After about a week of staring at perfectly good code for writing to the ALSA sound drivers from PD and wondering why it didn't work I finally realized that I was giving the read/write commands the size parameter in number of samples instead of bytes! It is always the easy things that are hard to debug. Regardless, full duplex now works. I need to do some more testing and get the buffering nice, add the extra command line parameters to choose between the different modes, and everything will be through (well, no raw midi support and probably nothing beyond two channels in four out until the ALSA people decide how best to support multi-channel cards like the Hammerfall).
One question about the OSS code - what is the advantage to the interleaving scheme used? It is not the most obvious way to me (though that doesn't mean much after this week), so I thought there must be a reason to go to that trouble.
Karl
-- _____________________________________________________ | Karl W. MacMillan | | Peabody Institute of the Johns Hopkins University | | Network and Telecommunications Services | | karlmac@peabody.jhu.edu | | 410/659-8297 |