ALSA pcmv2

[Karl MacMillan]

> 
> 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 at peabody.jhu.edu                           |
> > | 410/659-8297                                      |
> > -----------------------------------------------------

-- 
_____________________________________________________
| Karl W. MacMillan                                 |
| Peabody Institute of the Johns Hopkins University |
| Network and Telecommunications Services           |
| karlmac at peabody.jhu.edu                           |
| 410/659-8297                                      |
-----------------------------------------------------