Dave Phillips wrote: I believe that applications shouldn't use ALSA or OSS directly, but instead use either JACK or PulseAudio interfaces, depending on the application's goals and target user group. IMO, there's no superior audio/driver API. All current systems seem to lack support for the things which are supported on "competing system". Namely 3D audio API and hardware acceleration and support for advanced DSP or hardware acceleration functionalities. If we assume that general user owns something like SB Audigy/X-Fi, then the hardware is not very extensively utilized in current Linux systems (?). One of the good sides of OSS has been the ease of setting it up. If the user (possibly a client) doesn't have extensive knowledge about Linux or computers, setting up something like asound.rc might not be very straightforward, and instructing such users over a phone or email can be challenging too... BR, - Jussi

Does this mean that pulseaudio is preferred to Jack? Victor ----- Original Message ----- From: "Jay Vaughan" <jayv(a)synth.net> To: "victor" <Victor.Lazzarini(a)nuim.ie> Cc: <linux-audio-dev(a)lists.linuxaudio.org> Sent: Sunday, January 20, 2008 9:28 AM Subject: Re: [LAD] alsa and OSS (again?)

victor wrote: For desktop and user applications yes, for professional audio no. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Well behaved women rarely make history." -- Dorothy Parker

Arnold Krille wrote: Unless theres some reason I can't think of, why not use the "some kind of media-framework" KDE already made - phonon? -Joe

On Jan 20, 2008 2:22 PM, Jay Vaughan <jayv(a)synth.net> wrote: It takes quite some work to design an audio application that will be realtime safe. Multimedia players don't bother (why should they ?) thus they can't be good jack clients (although, some of them are, but it's not a prerequisite for a player). This doesn't prevent them from being (eventually) good pulseaudio client. If you wish to see one day every Linux desktop PC with realtime audio working right just to play an simple audio file... You'll have to wait quite a long time :-p __________________ Marc-Olivier Barre, MarcO'Chapeau.

Ok: my next question is, given that a software has native alsa support, Jack support, do we need to put some effort into adding 1) pulse audio support and 2) OSS support? Is that a good idea or is it just a waste of time? Victor ----- Original Message ----- From: "Jay Vaughan" <jayv(a)synth.net> To: <linux-audio-dev(a)lists.linuxaudio.org> Sent: Sunday, January 20, 2008 1:22 PM Subject: Re: [LAD] alsa and OSS (again?)

Jay Vaughan wrote: Hi Jay, Hmm. That equation don't hunt here. The MidiShare codebase is in dire need of attention for 32-bit Linux and won't currently compile at all for 64-bits. Ask me, I've been wrestling with its outdated source tree for the past week or so. Yann is planning to fix it, but he's got other work going on. Btw, many thanks to Albert Graef for the patches in the MidiShare package at the Q site, they finally made it possible to compile MidiShare on my OpenSUSE (JAD) box. I wouldn't have known about them at all if it weren't for a recommendation from Karim Haddad. Best, dp

Jay Vaughan wrote: Hi Jay, I'm not complaining about MidiShare as a solution, and I agree that it's a great project. You can look at Albert's patches to see what he fixed that enabled a clean compile. They're at http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=… in the midishare-1.9.1 package. Have you contributed your code to the MidiShare source tree ? Best, dp

Albert Graef wrote: Thank you, Albert, I did compile it with your patches. :) It's working fine with Open Music now. I also had to build the Player and Recorder, I don't recall any trouble with them. Best, dp

Jay Vaughan wrote: Hi Jay, I don't think anyone's saying it doesn't. Some of us have faced problems with its makefile structure and some of its code. For example, the Player and the Recorder weren't built by default, and there appeared to be no 'make player' type of command at the top-level. Btw, does your fork address the 100 MHz timing issue ? Best, dp

Fernando Lopez-Lezcano wrote: True, but (1) as you mentioned, the barrier to entry is high, and (2) even if it is accepted, who is going to maintain it? Researchers are usually busy with other things, and are not delighted by the prospect to go with each and every new kernel release just to update a single driver. ;-) Maybe it's possible to unbundle the MidiShare Linux driver from the main sources. That alone would make it much easier to provide frequent updates or patches for different kernel versions, and would provide a path to get the driver into the kernel at some point. From my experience, the rest of the MidiShare sources should compile on any modern Linux distro without much ado. (Well, the old gtk apps included with Midishare can be a headache since they require the gtk1 compat libs, but this could be made a configure-time option.) It would certainly be nice if PlanetCCRMA included Midishare again. :) I'm currently getting a new laptop on which I can finally run PlanetCCRMA alongside with SUSE again, so I'll probably look into that when I have the time. It shouldn't be too difficult to adapt my patches for FC8. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

On Mon, 2008-01-21 at 07:32 +0100, Albert Graef wrote: Yes, but it is the only way to make midishare "mainline". So that it will always work with any vanilla distribution kernel (that has, of course, enabled its build). The other option would be to implement all of midishare in user space. Well, the kernel maintainers of course. And whoever is maintaining it now (sorry, I don't who that might be). I don't see what is the problem. Assuming the kernel module is merged in (that might not be easy, of course) then it will have to be kept up to date with the mainline kernel but that is good. And probably not that much work, after all the midishare kernel module is not evolving, right? They don't need to update the kernel. Why would they? The midishare kernel module will keep working on the older kernels, right? That would be a good first step. The "kernel module problem" is still there. I do distribute my own kernels (not that I like to do that :-) but some users use the normal Fedora kernel. Then I would have to track the Fedora kernels and build midishare modules for them as well. And right now Planet CCRMA does not have any software that needs it (except maybe for Common Music but I have been using portmidi for that - yuck...) -- Fernando

Ivica Ico Bukvic wrote: I think there's a misunderstanding there. The goals of these projects are different. Midishare doesn't aim to replace ALSA, in fact it works with ALSA sequencer (as well as OSS and a number of other interfaces on different platforms). Midishare is a high-level, cross-platform MIDI API which has been around on various platforms long before ALSA, and even before Linux was a blink in Linus' eye. It's similar in scope to PortMidi, but more mature and offers more features. In fact I think that the ALSA sequencer was inspired by Midishare in some ways, but that doesn't mean that one should be replaced by the other. Some ppl prefer the features and cross-platform compatibility that Midishare offers, others don't want an extra layer between them and their MIDI interface and don't care about cross-platform compatibility, so they rather go with plain ALSA instead. To each his own. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

On Mon, 2008-01-21 at 16:18 -0500, Ivica Ico Bukvic wrote: I think this is entirely accurate. the distributions and other "desktop" organizations are tired of ALSA as "the solution", and are embracing PulseAudio and various similar efforts/wrappers (e.g. Phonon on KDE). ALSA is going to vanish as an API for all but those developers who don't know how to use google. Pulse even has plans to "replace" JACK one day, but its lead author fully understands the challenge there. --p

El Tuesday 22 January 2008 18:03:55 Ivica Ico Bukvic escribió: My point of view as user and amateur programmer is not so good, with all the respect to everybody, the linux MIDI/Audio world seems an API contest, I don't have knowledge to judge APIs, probably all are so good, but in the non expert user side all of this generate more confusion. Hope with jack-midi we reach a definitive solution for audio/midi in linux, probably the transition starts now. Maybe some day the RT patches will be inside the kernel in all of the distros, and the desktop users will run linux audio apps without "external" problems. Can the linuxaudio consortium put some pressure right now to the kernel team? Josep

On Wed, 2008-01-23 at 04:11 +0100, Lars Luthman wrote: and include user space configuration so that SCHED_FIFO and memlock are available to non-root users.

I agree with you - there is an API siege mentality - but you know what? Its the people who put the effort into making a working distro out of the results, and pushing that into a really working environment, who will make the difference in this regard. It doesn't matter if MidiShare or ALSA or Jack or Pulseaudio all get serious developer attention: the 'last mile' of the whole issue is going to be solved by those guys who do the humble and inglorious, yet highly respectable, work of putting it all together into a working distribution. I hope there continues to be some heat on the JACK core to get things right, and I also hope that there continue to be alternatives proffered in light of the stagnation that inevitably occurs when people are doing things for love, and little other motivation. ; -- Jay Vaughan

On Mon, Jan 21, 2008 at 10:04:54PM -0500, Paul Davis wrote: The only parts that will remain are probably the hw: devices, which generally work well and provide the low-level access that you need to build things like JACK on. The _technical_ reasons why dmix/dsnoop apparently can't be made to work as expected remain a mystery to me. It's not because 'this can't be done in user space' as has been said IIRC on the OSS author's blog. JACK does it in user space. Maybe the project has fallen victim to it's own ambitions of providing all sorts of everything to everyone - a range of access methods (mmapped, blocking, non-blocking, callback,...), and the whole collection of soft devices it can create to keep everybody happy. I guess that in the end the number of possible combinations just exploded and became to large to handle. Organising things this way was IMHO a bad idea. Instead of trying to anticipate each and every type of device an application writer would ever want to talk to, it seems safer to provide just a single interface, which should be close to the hardware, and then a number of libraries (instead of the preconfigured soft devices) to help applications to convert to whatever they want, providing things like e.g. sample rate conversion, easier non time-critical access, etc. Also, if the audio hardware has to be shared, then no single app that just happens to produce some sounds should _ever_ have been allowed to think it could configure the hardware, to select sample rates or formats. Just as normal apps are not expecting to be able to format a disk, or to configure the network interfaces. Part of the blame is with the authors who insisted on being able to do such things, even if the primary function of their app was not related to audio at all, just because it was easier. There are other problems of course, one of them being documentation about the *design* of the system, not just the API. I once tried to debug an ALSA driver, but had to abandon the exercise. Almost everything in the drivers seems to be done by callbacks and endless levels of indirect calls via function pointers that are initialised in dark places, and that makes it very difficult to understand what's happening, and where. The only way out (or in, for a driver developer) is system design documentation, which is non- existing AFAIK. I haven't looked at OSS for a long time, not since the first ever LAC presentation I heared was the one by Takashi, on ALSA. But I will look at it again, even if for most of my work it's not really relevant - JACK rules. Caio, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

On Tue, 2008-01-22 at 00:09 +0100, Albert Graef wrote: It would make a BIG difference to have all of midishare in userland. I think the latest kernels implement high resolution timers, etc. If Jack can be made to work in userland, midi should be possible as well. I don't think I follow you. Who is "you"? The midishare developers? If I understand the kernel development process correctly, once the midishare kernel module is in the mainline kernel the update process is fairly automatic. As long as the internal kernel api's don't change in ways that are incompatible with the module then no change or intervention is needed. If there is a change the midishare developers will get notified and them or some other kernel hacker will do it or help. Which is much better than responding to things when they break. If "you" means me as a packager then I would have less work to do if midishare is part of the miainline kernel. It would not add to the workload at all. Whatever I release would automatically include midishare 'cause it is in the kernel as I build it. It is more work to have it as a separate module (and that's why I dropped it as soon as it was not longer required by other packages in Planet CCRMA). -- Fernando

There are no kernel drivers in MidiShare, only kernel modules. The drivers sit in user space and are not dependent on the Linux drivers unless you deem it so .. I'm guessing the hard-coded paths and the sub-tree Makefile scheme in MidiShare presented a dilemna? ; -- Jay Vaughan

Well I have it working fine on both 2.4 and 2.6 kernels, so I don't know what the dilemna is here, really .. maybe it is a drag to compile from source, but to be frank, I think MidiShare is one of the most friendly source trees to present this situation. And actually I really like the Midishare design - kernel module for the queues, and user-space for drivers .. this setup works really well, surprising enough. This is not MidiShare's fault. Maybe some would be happier when someone packages it up into a .deb or .rpm, but the fact is that MidiShares' design allows this to occur quite easily. Someone just needs to do it for the distro. My experience is that very few people are enlightened as to the reasons for why they may want to do this in MidiShares' case .. it is a bit of an (unjustly, imho) underdog in the Linux/MIDI realm .. On my GP2X machine (which has been running MidiShare for a few years now) I have the MIDEX driver, firmware loader, MidiShare kernel and user space modules, all happily being handled by an /etc/init.d/ midishare [start,stop,status] style config .. on my Intel machine (Ubuntu), I sometimes go through the alsa-midi layer, but most of my work (and interest in the first place) is with MIDI on ARM. But the question is: Which Linux (distro)? Like I say, MidiShare is well-written such that it can be easily integrated into the folds of most distro's. Its just that very few have done the last-step distro- integration work to make it easy, and thus: for now you gotta go with the source. Maybe MidiShare needs a packager/evangelist to get the last steps done, so people can see just why this wonderful API/Driver/subsystem is worth the effort. I'm having an awful time trying to get ATI Mach64 driver support done on a Ubuntu Studio installation. MidiShare, on the other hand, was smooth and easy on the same machine .. I'd be willing to help with any and all MidiShare problems, honestly. I think its a wonderful, stable, productive way to do MIDI on Linux. If only more people knew about it, and ditched the attempt at re-inventing a well-rounded wheel, already. The MidiShare design lends itself to integration with JACK, for example, very, very well .. ; -- Jay Vaughan

Jay Vaughan wrote: Judging from what I read on the Midishare list, most Linux users of Midishare indeed have trouble dealing with compilation probs in the kernel module. Not you and me, but you can't expect end users to be able to handle problems due to the ever-changing kernel API. This stuff isn't trivial. You don't have to be a kernel hacker (I'm certainly not), but you really need to understand the Midishare code if you have to sift the kernel headers for a replacement for some kernel routine which just miraculously disappeared, thanks to your friendly kernel dev cleaning up the kernel code. I've done it more than once... Nobody argues that. I'm also using it for all my MIDI needs. Of course not. But you still have to deal with it. :) That's what I call the Midishare driver. As I said, the userspace stuff, Midishare library and all that, compiles quite easily on almost any Linux system. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag