Hi all,
concerning the RME and ALSA issue, there now is another solution:
I got the new RME card and since jack doesnt't work properly on my laptop, got the idea to adapt pd to use Bill Schottstaedt's sndlib for better ALSA compatibility. Stefan Kersten helped and wrote the patch 3 weeks ago. It works without any problems (I used it in 2 concerts and a 1 week installation workshop).
The patch makes pd work with all cards, which work with the snd program of Bill Schottstaedt (also the RME 9652). For the Hammerfall to work you have to set an environment variable $SNDLIB_ALSA_PLAYBACK_DEVICE to "default:0,0". This is an ALSA software layer which converts the interleaced samples into non inteleaved. And of course you need to have the sndlib installed.
I could send the patch but would prefer Stefan doing it, as it's his work and he only sent me a preliminary hack shortly before I had to head off for the workshop.
Yours, Orm
P.S.: It might be a good idea to add a configure flag like --with-sndlib to compile pd against this library for future releases as it seems to be a cleaner interface to ALSA than the old pd code.
On Tue, 13 Aug 2002, Orm Finnendahl wrote:
I got the new RME card and since jack doesnt't work properly on my laptop,
What kind of problems do you have ?
The patch makes pd work with all cards, which work with the snd program of Bill Schottstaedt (also the RME 9652). For the Hammerfall to work you have to set an environment variable $SNDLIB_ALSA_PLAYBACK_DEVICE to "default:0,0". This is an ALSA software layer which converts the interleaced samples into non inteleaved. And of course you need to have the sndlib installed.
The problem with this solution is that we are first converting from non-interleaved into interleaved and then back into non-interleaved.
In the OSS portion of pds code this is handled the proper way. There is no unecessary conversion done.
The ALSA code in pd is just missing the direct way, that is, sending non-interleaved samples.
Guenter
I could send the patch but would prefer Stefan doing it, as it's his work and he only sent me a preliminary hack shortly before I had to head off for the workshop.
Yours, Orm
P.S.: It might be a good idea to add a configure flag like --with-sndlib to compile pd against this library for future releases as it seems to be a cleaner interface to ALSA than the old pd code.
Hello Günter,
Am Dienstag, den 13. August 2002 um 11:15:58 Uhr (+0200) schrieb günter geiger:
On Tue, 13 Aug 2002, Orm Finnendahl wrote:
I got the new RME card and since jack doesnt't work properly on my laptop,
What kind of problems do you have ?
I get nasty xruns everytime, my system accesses the disk (appr. every 3-4 secs). I posted this to the jackit-dev list and Paul Davis replied stating that jack is intended as professional (sic!) solution with very low latency, that he's using SCSI therefore and he didn't seem to care a lot. BTW: Increasing the period size doesn't help. I'll give it another try with a low latency patch applied to my system (Debian with 2.4.18). Maybe that fixes it. But for installations or concert situations I need a reliable system which works unattended for days and therefore prefer the direct way, where pd just grabs the driver.
The ALSA code in pd is just missing the direct way, that is, sending non-interleaved samples.
Are you sure, ALSA can handle this? I thought, ALSA doesn't work with uninterleaved samples. If that's the case, I'd much prefer the direct way of course.
Who can help in that respect? ALSA documentation is still hardly more than nonexistent and the API far from straightforward.
-- Orm
On Tue, 13 Aug 2002, Orm Finnendahl wrote:
Hello G�nter,
Am Dienstag, den 13. August 2002 um 11:15:58 Uhr (+0200) schrieb g�nter geiger:
On Tue, 13 Aug 2002, Orm Finnendahl wrote:
I got the new RME card and since jack doesnt't work properly on my laptop,
What kind of problems do you have ?
I get nasty xruns everytime, my system accesses the disk (appr. every 3-4 secs). I posted this to the jackit-dev list and Paul Davis replied stating that jack is intended as professional (sic!) solution with very low latency, that he's using SCSI therefore and he didn't seem to care a lot. BTW: Increasing the period size doesn't help. I'll give it another try with a low latency patch applied to my system (Debian with 2.4.18). Maybe that fixes it. But for installations or concert situations I need a reliable system which works unattended for days and therefore prefer the direct way, where pd just grabs the driver.
Yes, you are definitely right, for concert situations and installations it is the more reliable solution.
I have heard from several sources already about the problems they have with jack, others OTOH say it works perfectly, I think that there is a bit of voodoo involved in that :).
The ALSA code in pd is just missing the direct way, that is, sending non-interleaved samples.
Are you sure, ALSA can handle this? I thought, ALSA doesn't work with uninterleaved samples. If that's the case, I'd much prefer the direct way of course.
Who can help in that respect? ALSA documentation is still hardly more than nonexistent and the API far from straightforward.
Someone with enough time, programming experience and the ultimate goal to save the (musicians) world with free software :) No, honestly, I have looked at the code a bit already, then I got stuck because it is a bit a try and error sort of programming. Now currently my desktop machine which hosts the Hammerfall is broken :(.
I think alsa offers now two different "write" and "read" functions, one for interleaved and anotherone for non-interleaved.
Guenter
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2122" "Tuesday" "13" "August" "2002" "16:38:39" "+0200" "=?X-UNKNOWN?Q?g=FCnter_geiger?=" "geiger@xdv.org" nil "53" "Re: [PD-dev] alsa rme pd again" "^Resent-Message-ID:" nil nil "8" nil nil (number " " mark " =?X-UNKNOWN?Q?g=F Aug 13 53/2122 " thread-indent ""Re: [PD-dev] alsa rme pd again"\n") nil nil nil nil nil] nil) Received: from list by web.iemnet with local (Exim 3.35 #1 (Debian)) id 17ed7s-0007mA-00; Tue, 13 Aug 2002 16:58:28 +0200 In-Reply-To: 20020813130031.GB613@finnendahl.de Message-ID: Pine.LNX.4.31.0208131616330.24355-100000@xdv.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailing-List: pd-list@iem.kug.ac.at archive/latest/89 X-Loop: pd-list@iem.kug.ac.at Precedence: list Resent-Message-ID: K6hCUD.A.ULH.22RW9@web Resent-From: pd-list@iem.kug.ac.at Resent-Sender: SmartList list@iem.kug.ac.at Resent-Bcc: Resent-Date: Tue, 13 Aug 2002 16:58:28 +0200 From: =?X-UNKNOWN?Q?g=FCnter_geiger?= geiger@xdv.org To: Orm Finnendahl finnendahl@folkwang-hochschule.de cc: pd-list@iem.kug.ac.at Subject: Re: [PD-dev] alsa rme pd again Date: Tue, 13 Aug 2002 16:38:39 +0200 (CEST)
Hello,
[...]
The ALSA code in pd is just missing the direct way, that is, sending non-interleaved samples.
Are you sure, ALSA can handle this? I thought, ALSA doesn't work with uninterleaved samples. If that's the case, I'd much prefer the direct way of course.
Who can help in that respect? ALSA documentation is still hardly more than nonexistent and the API far from straightforward.
Someone with enough time, programming experience and the ultimate goal to save the (musicians) world with free software :) No, honestly, I have looked at the code a bit already, then I got stuck because it is a bit a try and error sort of programming. Now currently my desktop machine which hosts the Hammerfall is broken :(.
I think alsa offers now two different "write" and "read" functions, one for interleaved and anotherone for non-interleaved.
I think we should have a look on some CASE Studies to get to an answer.
Here my experience ALSA:
Last I tried ALSA-RME/pd was 1.5 years ago (Hammerfall, not DSP one): The ALSA RME drivers supports mmap interface and non-interleaved samples in native mode, (but no interleaved stereo which is as bad as my first driver), so thanx to guenter he made a kind of oss driver (in kernel now) out of it, so a additional stereo-device exist.
But if you use alslib, which is the preferred way there is always a copy from Soundcardbuffer to a alsabuffer to pretend memory map, so the memory mapping of the soundcardbuffer isnt accessed directly, also the samples are not converted for example in floats, so pd has to copy an convert again. Anyway when I got something to work (from examples) there was a new release which broke everything even that I used alsalib (maybe using the alsa devices is more stable), so my decision was dont touch ALSA again until it will be 1.0 and stabilize, which was said to be soon, but now its 1.5 years later and no 1.0.
I would like to find an answer to following questions, how to set up linuxboxes with pd in studios to be used by students, componists, etc.:
Question A: What is the preferred way to use pd and other soundapps with hammerfall to get small latency and stable drivers and many apps which are supported by this ?
Since now computers quite fast so one copy more is not taking 10% of CPU-time like in last days: We used pd with 2 hammerfalls and 48 channels on PIII 800MHz taking about 20-30% of CPU only for a copy through on pd within 10ms, on a Athlon 2000+, DDR-RAM it took about 5% and we got to 5ms.
Question B: Has sombody experience with ALSA drivers ?
Question C: Has sombody experience with 16(8)-channels usage on an Hammerfall DSP and laptop and/or Desktop ?
mfg winfried ritsch
-
g�nter geiger -
Orm Finnendahl -
Winfried Ritsch