Hi,
Hi Wini,
Thanks for this (I'll buy you a beer in Graz...) I think the best way to use it is to call the alsamm functions automatically if the regular (interleaved non-mmap) mode isn't available. I put a non-interleaved non-mmap attempt in s_audio_alsa.c, but apparently the alsa driver simply doesn't work for that case (crashes the machine) so I won't mind simply replaceing that with the code you wrote. Then there won't have to be an extra API choice...
I was not really sure how to handle this, but you are right. I didnt test but if the other alsa_implementation is not really stable I can try to fix them and mix them in my sources, i think they are just not up to date.
The point is, if alsa driver access with noninterleaved and read-write is done good, we should be able to use this also for the hammerfall cards with the plug, dmix, dsnoop, ... devices for better mix of audio cards ... but anyway this can be done with alsa driver configuration and so we dont need extra alsamm package.
In any case everyone (especially linux specialists ;-) can use jack, since you can mix and connect many apps in jackd with the same sound card, but for some reasons of thread priorities and concurrent processes the jack implementation doesnt work always (and is as ignorant to sync ;-) like the alsamm drivers.
I have also another question I realized doing the drivers:
startup:
if pd is started, then the engine is also started (open and senddacs) but DSP is shown off. On first DSP-ON card is not opened but then on DSP OFF and DSP ON the drivers are closed and openend again.
Should it better do a device open ad setup if DSP ist set explicitly ?
if I stop the device (DSP OFF) and some app open it you cant start it again. Could it be a problem, since on my implementation it just tests for other devices and takes next card...
Would it not be nicer to open the Soundcard on startup and on a MEDIA-Dialog (I never use, but maybe somebody does) change and close it on pd exit (and maybe with the mediadialog) and have additional functions for to start/stop the driver. So devices are always opened and doesnt need to be allocated every DSP ON/OFF. (also faster DSP On/Off reaction).
Or should the _open routine ask for first open and open once ?
I'll try rolling this into my upcoming 0.38. Unfortunately the code is broken in other respects right now and wouldn't be suitable for checking into CVS; so I'll just upload a tarball for people to grab if they want to try it.
thanks, so If you want me to do something before/after the merge just let me know.
mfg winfried