but what is wrong with the oss-drivers ? (something is wrong: AES/EBU-in will not work with hw-revision 1.5;

but

i think it doesn't work under also too)

mfg.cd.sadf IOhannes

I don't mean to instigate a flame-war, but [according to my personal opinion] in a nutshell -- a lot. :-(

For instance:

• I cannot run Ardour, nor most of other Alsa-specific apps (whereas the

other way around is in most cases quite possible)

• OSS uses "interleaved" approach to provide multi-channel capabilities,

even for RME that does not have interleaved output. This results in redundant software resampling (unless something has been dramatically changed in recent incarnations of the OSS architecture of which I am not aware, please correct me if I am wrong)

• OSS is a standard propelled by a commercial company (and that is

included in the open-source kernel, somehow I find it hard to believe that the mix between commercial and open-source is good for the long-term growth, although retrospectively speaking I am very thankful to the 4fronttech for providing sound support for the Linux platform when it needed it the most and when no one else was able/willing to provide one)

• OSS's interest is in multiple platform support, rather than the

maximum platform-specific performance

• Finally, last time I tried OSS RME Hammerfall driver (v0.8 a couple of

days ago), nothing worked as it was supposed to (although obviously I did not give it enough of a chance, I am sure).

Thanks for your response nonetheless. I would greatly appreciate it to hear from someone who has tried a more recent implementation of Alsa, as well as from the current Pd developers whether they know just how far away is the stable implementation of ALSA+Hammerfall+PD.

Thanks! Sincerely,

Ico http://meowing.ccm.uc.edu/~ico/

:) yes, but some times you are not able to run ALSA specific apps on ALSA ... and exactly this is the problem with ALSA support for pd, once added it was constantly breaking on each update. I have been assured that this is not going to happen that often now the API is stable, but still this was the main reason I stopped implementing things in ALSA some years ago, ...

This is a worn-out (and at this point anything but true!) argument against ALSA. You should have checked it out in the past 4-6 months, and (apart from the anemic documentation) would have realized not only that it's API is pretty much frozen (i.e. no backwards compatibility-breaking changes), but also that it is now a 2.5 kernel API as well (Linus just recently posted a note about this in an e-mail saying that he just simply did not yet get around it, but it should be in there any day now). Besides, give me one Alsa app that does not run under Alsa (that is still being maintained -- in other words, it is still current). Granted, not all OSS-only apps work well with Alsa (at least not yet, due to primary focus of the Alsa devel team to finish-up the main portions of the API, and then worry about OSS emulation), but that is still much, much better than the other way around (where no Alsa apps work with the OSS)...

...

• OSS uses "interleaved" approach to provide multi-channel

capabilities,

...

even for RME that does not have interleaved output. This results in redundant software resampling (unless something has been

dramatically

...

changed in recent incarnations of the OSS architecture of which I am

not

...

aware, please correct me if I am wrong)

this is wrong for the RME Hammerfall.

In what sense? I am 100% sure that Hammerfall is one of the few non-interleaved cards. So does this mean that your OSS driver addresses this issue or is it that you believe that Hammerfall is interleaved after all?

...

• OSS is a standard propelled by a commercial company (and that is

included in the open-source kernel, somehow I find it hard to

believe

...

that the mix between commercial and open-source is good for the long-term growth, although retrospectively speaking I am very

thankful

...

to the 4fronttech for providing sound support for the Linux platform when it needed it the most and when no one else was able/willing to provide one)

wrong too, OSS used to be the native linux sound API.. (AFAIK still

is,

I haven't looked at 2.5)

I don't see anything wrong with this statement, so I am not quite sure what are you labeling *wrong*. Linus originally gave 4fronttech the "thumbs-up" to build these drivers because Linux needed audio support. But it WAS and still IS a commercially driven API. Just because it resides in kernel space, it does not mean that it still is [or that it will remain to be] a *default* API. 2.5 kernel is introducing ALSA in the kernel space, so things are about to change (and from the hints I've been getting, OSS will be slowly phased out)...

...

• OSS's interest is in multiple platform support, rather than the

maximum platform-specific performance

• Finally, last time I tried OSS RME Hammerfall driver (v0.8 a

couple of

...

days ago), nothing worked as it was supposed to (although obviously

I

...

did not give it enough of a chance, I am sure).

... well who knows, at least this way we won't find it out.

Guenter

Please don't get me wrong, but I have no time to fiddle with a driver that has little or no docs. While ALSA has a similar problem of lack of documentation, I found ALSA's mailing lists more than helpful. If one can point a good OSS mailing list (other than 4fronttech's), I will possibly reconsider delving into the OSS version of the driver (at least for the time being and for particular tasks, until the OSS emulation gets better in ALSA)...

Sincerely,

Ico

-----Original Message----- From: Frank Barknecht [mailto:barknech@ph-cip.uni-koeln.de] Sent: Wednesday, February 13, 2002 6:56 PM To: pd-list@iem.kug.ac.at Subject: Re: [PD] what is the current state of the support for the

Alsa

Hammerfall driver?

Ivica Bukvic hat gesagt: // Ivica Bukvic wrote:

...

API is pretty much frozen (i.e. no backwards compatibility-breaking changes), but also that it is now a 2.5 kernel API as well (Linus

just

...

recently posted a note about this in an e-mail saying that he just simply did not yet get around it, but it should be in there any day now).

Linus has done it today:

Date: Wed, 13 Feb 2002 12:26:06 -0800 (PST) From: Linus Torvalds torvalds@transmeta.com To: Alan Cox alan@lxorguk.ukuu.org.uk Cc: [...]

On Wed, 13 Feb 2002, Alan Cox wrote:

...

Waste of effort. ALSA will replace the OSS code anyway

In fact, in my tree it right now has replaced it. I'll make a

pre-patch

and try to get the BK tree pushed out.

            Linus

Ciao

Amen to that :-)

Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster & computer consultant http://meowing.ccm.uc.edu/~ico/ ico@fuse.net ============================ "To be is to do" - Socrates "To do is to be" - Sartre "Do be do be do" - Sinatra "I am" - God

vanDongen/Gilcher hat gesagt: // vanDongen/Gilcher wrote:

The biggest problem currently with ALSA is the .asoundrc file. With a hammerfall it is usually neccesary to set up one, unless you want to use non-interleaved 24 channel audio. This thing is _really_ poorly documented, but if you search on alsa-dev you can find examples that help a bit.

With my Midiman card I can in most cases (and in other software, not PD, where this is not an option yet) just use the "default" plugin PCM, that is preconfiguerd by ALSA.

I think that most problems come from not setting up the correct audio device for the application using ALSA's conversion library, but instead trying to access the hw directly with some format that the hardware doesn't support.

Another quick fix is to use plughw:0,0 as your devicename in stead of hw:0,0

This isn't possible, at least with pd-0.35+test3, because of the hardcoding if "hw:x,x" in s_main.c. And this might be the reason, why PD gives problems with a Hammerfall and ALSA. It maybe has a too naive alsa-device selection option. Currently this is:

-alsadev <n> -- ALSA device # (counting from 1) or name: default hw:0,0

The "hw" PCMs in ALSA can be tricky. The plugin layer in ALSA is better suited for normal usage. Maybe it would be better, if the alsadev option allowed the user to specify the PCM on his own. A lot of ALSA native software (aplay/arecord, ecasound, Ardour,...) does it this way, to give the user flexibility through the plugin or the hardware layer.

Just specifying a device number might be to limited for some use cases.

Ciao,

                                             __    __

Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___\ / / / ____/ / / / // ____// /\ \ ___\____ \ /_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\

I have a patch that whenever I reopen it the "toggle" objects are moved - everything else is in place and fine. I have tried deleteing them - redrawing and saving. Is this a bug or is there something I can do about it?

mark

I think this was as far as I got too:

On Thu, Feb 14, 2002 at 12:28:23PM +0100, Frank Barknecht wrote:

Frank Barknecht hat gesagt: // Frank Barknecht wrote:

...

But somehow I cannot use the plugin layer: "-alsadev plughw:0,0" or "alsadev default:0,0" gives a stuck Audio I/O:

ALSA lib pcm_hw.c:145:(snd_pcm_hw_hw_free) SNDRV_PCM_IOCTL_HW_FREE failed: File descriptor in bad state snd_pcm_close (input): File descriptor in bad state ALSA lib pcm_hw.c:145:(snd_pcm_hw_hw_free) SNDRV_PCM_IOCTL_HW_FREE failed: File descriptor in bad state snd_pcm_close (output): File descriptor in bad state

if any ALSA experts can recognize this error message that might help...

cheers Miller

On Wed, 13 Feb 2002, Ivica Bukvic wrote:

Please don't get me wrong, but I have no time to fiddle with a driver that has little or no docs. While ALSA has a similar problem of lack of documentation, I found ALSA's mailing lists more than helpful. If one can point a good OSS mailing list (other than 4fronttech's), I will possibly reconsider delving into the OSS version of the driver (at least for the time being and for particular tasks, until the OSS emulation gets better in ALSA)...

Sincerely,

You asked me about support for a driver that is free and *working* I told you that you should remove the alsa driver before you try loading the rme96xx driver, and the next thing I hear from you is that you are lamenting on a public list about my driver not working.

Maybe this made me overreact a bit. Sorry, and thank you for pointing out the problems you see with OSS, be assured that personally I think that ALSA is much superiour to OSS, but at the same time you might accept that I had very good reasons for writing the OSS driver. (which was actually not much more than changing Winfrieds driver to include interleaved mode for standard OSS apps).

Guenter

Hi,

günter geiger hat gesagt: // günter geiger wrote:

:) yes, but some times you are not able to run ALSA specific apps on ALSA ... and exactly this is the problem with ALSA support for pd, once added it was constantly breaking on each update. I have been assured that this is not going to happen that often now the API is stable, but still this was the main reason I stopped implementing things in ALSA some years ago, ...

Some years is really a long time. The last bigger change in ALSA's API since months was the moving of the ALSA header files from sys/ to alsa/. This resulted in some compiler warnings about a deprecated header location, but nothing else. The next change is a renaming of kernel modules in CVS, that was required by Linus for the inclusion of ALSA in kernel 2.5. Some simple alias definitions should fix that, too.

Apart from that, the 0.9.0 API is very stable. I have some ALSA native apps (that included PD) running here without problems through at least 5 minor beta versions of ALSA without the need to recompile. And PD I of course recompile with each new version, here I can use anything from beta6 (or older, don't remember) to beta10: PD will work anyways.

I have no experience with RME cards, but I don't understand, why it should be recommended to use OSS drivers for a "Pro" card like the Hammerfalls, when ALSA tries to build the "Pro" API.

I'm just asking myself: What should I (we) tell someone that intends to use a Hammerfall with PD: Install ALSA, or install the OSS drivers? Will PD work with RME/ALSA? The anwer given on linux-audio-[dev|user] is usually ALSA.

Alaaf,

                                             __    __

Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___\ / / / ____/ / / / // ____// /\ \ ___\____ \ /_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\

Hi all,

Last time I tried to run Pd with RME Hammerfall under Alsa, I couldn't make it work. I have no idea whether it was a problem in Pd or somewhere

else.

Pd does run with ALSA 0.9 for other hardware, so in principle it

should

be possible to get it running with the Hammerfall as well, but I

wasn't

able to figure out how.

We've been using the OSS RME driver here (Guenter's.) I'd prefer to

have

Pd able to run either way, but haven't wanted to go back to the ALSA driver and try to figure out what was wrong. ALSA has been

frustrating

to work with because of the scanty documentation, and I've been

waiting

for them to improve that before investing more time in it...

cheers Miller

It seems I'll just have to try it out and see ;-). Btw, did you try to use .asoundrc file in your home dir? Possibly that would address the issue, since Hammerfall does not have a hardware mixer, so it has to be addressed differently.

Ico