Hello,
PD's ALSA Interface is not working with Hammerfall RME96xx, HDSP96xx and HDSP-MADI cards, since we need this I have implemented a seperate ALSAMM Interface. I can get good latency responses (6.9ms stable) and also added multicard support.
For a first try you can get it here:
http://puredata.org/Members/ritsch/pd_alsa_mmap
I dont know if I should or someone else will insert this in cvs (since I have no access to pd-cvs at the moment) and make maybe a alsamm branch for first implementations until several poeple have reported it stable (or noone reported it broken in one month ;-))) before do a merge.
Any suggest ?
Please report sucessfull usage and the configuration used.
mfg Winfried Ritsch
Hallo, Winfried Ritsch hat gesagt: // Winfried Ritsch wrote:
PD's ALSA Interface is not working with Hammerfall RME96xx, HDSP96xx and HDSP-MADI cards, since we need this I have implemented a seperate ALSAMM Interface. I can get good latency responses (6.9ms stable) and also added multicard support.
Cool. This will work for other cards (maybe not so fast) as well, will it?
For a first try you can get it here:
http://puredata.org/Members/ritsch/pd_alsa_mmap
I dont know if I should or someone else will insert this in cvs (since I have no access to pd-cvs at the moment) and make maybe a alsamm branch for first implementations until several poeple have reported it stable (or noone reported it broken in one month ;-))) before do a merge.
I don't think it would demand a new branch. This is stuff for the devel-branch, I think.
Ciao
I dont know if I should or someone else will insert this in cvs (since I have no access to pd-cvs at the moment) and make maybe a alsamm branch for first implementations until several poeple have reported it stable (or noone reported it broken in one month ;-))) before do a merge.
Any suggest ?
Please report sucessfull usage and the configuration used.
i tried your patch with both devel_0_37 and 0.37-1-alsamm and got some problems:
tim@laptop ~/pd/pd/src $ ../bin/pd -alsamm reading startup file: /home/tim/.pdrc pd_startgui : updater thread 16386 launched couldn't open MIDI input device 0 couldn't open MIDI output device 0 opened 0 MIDI input device(s) and 0 MIDI output device(s). alsa: max 4 output device allowed (extras ignored) error: No Accesstype SND_PCM_ACCESS_MMAP_NONINTERLEAVED: Invalid argument
error: playback device hwparam_set error:: Invalid argument
requested channels=0 but used=18 playback device hw:1 with 18 channels and buffer_time 46439 us opened error: No Accesstype SND_PCM_ACCESS_MMAP_NONINTERLEAVED: Invalid argument
error: capture device hwparam_set error:: Invalid argument
global soundfiler thread launched, priority: 0
<snip>
when i want to switch to alsamm in the menu->media->alsa i get:
error: Bad arguments for message 'audio-setapi' to object 'pd' ... you might be able to track this down from the Find menu.
my setup: hw:0 intel8x0 hw:1 hdsp alsa 1.0.5a kernel 2.6.6-mm1
any idea?
anyway, if no one objects, i'd add it to the devel branch ...
cheers... tim
Tim Blechmann wrote:
opened 0 MIDI input device(s) and 0 MIDI output device(s). alsa: max 4 output device allowed (extras ignored) error: No Accesstype SND_PCM_ACCESS_MMAP_NONINTERLEAVED: Invalid argument
my setup: hw:0 intel8x0 hw:1 hdsp
as far as i understand wini's implementation, only few cards (like the hdsp) will support the non-interleaved features that are required by alsamm. probably pd is trying to open the intel8x0 in non-interleaved mode and fails ?
mfg.a.sdr IOhannes
my setup: hw:0 intel8x0 hw:1 hdsp
as far as i understand wini's implementation, only few cards (like the hdsp) will support the non-interleaved features that are required by alsamm. probably pd is trying to open the intel8x0 in non-interleaved mode and fails ?
that would make sense ... but i think there are a couple of laptop's out there having one onboard chip and an hdsp for audio ... adding alsamm to pd would make more sense, if one wouldn't first have to unload the module for the other sound chip ...
wouldn't it be possible to define the devices alsamm should try to access? that would definitely make sense ...
cheers... tim
Hello,
Tim Blechmann wrote:
opened 0 MIDI input device(s) and 0 MIDI output device(s). alsa: max 4 output device allowed (extras ignored) error: No Accesstype SND_PCM_ACCESS_MMAP_NONINTERLEAVED: Invalid argument
my setup: hw:0 intel8x0 hw:1 hdsp
as far as i understand wini's implementation, only few cards (like the hdsp) will support the non-interleaved features that are required by alsamm. probably pd is trying to open the intel8x0 in non-interleaved mode and fails ?
thats true, and tests if multicard configuration will work is not very extensive. Maybe I should change this, so it picks only cards which can do this. As far as I know only few multichannel cards support this mode as hardwaredevice, and only hardware devices supports mmap Interface this way.
Anyway this driver superceeds the jack implenentation for special use-cases. So in most cases use jack.
mfg winfried ritsch
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'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.
cheers Miller
On Fri, Aug 06, 2004 at 04:47:19PM +0200, Winfried Ritsch wrote:
Hello,
PD's ALSA Interface is not working with Hammerfall RME96xx, HDSP96xx and HDSP-MADI cards, since we need this I have implemented a seperate ALSAMM Interface. I can get good latency responses (6.9ms stable) and also added multicard support.
For a first try you can get it here:
http://puredata.org/Members/ritsch/pd_alsa_mmap
I dont know if I should or someone else will insert this in cvs (since I have no access to pd-cvs at the moment) and make maybe a alsamm branch for first implementations until several poeple have reported it stable (or noone reported it broken in one month ;-))) before do a merge.
Any suggest ?
Please report sucessfull usage and the configuration used.
mfg Winfried Ritsch
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.at.gpg.net/)
--
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
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
-
Frank Barknecht -
IOhannes m zmoelnig -
Miller Puckette -
Tim Blechmann -
Winfried Ritsch