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
Sorry if this is a duplicate... I tried to reply but I believe my reply got eaten by the great postaman in the sky.
I'm about to release Pd 0.30, in a day or so I hope, just to warn everyone...
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
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 |
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 |
Karl MacMillan writes:
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.
Of course it would be better and faster if we could send the blocked data directly to the dacs. If the new ALSA API supports this,, we do it.
Guenter
-
Guenter Geiger -
Karl MacMillan -
Miller Puckette