Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
At Thu, 16 Jun 2005 10:30:29 -0400, Paul Davis wrote: i don't think that, even if we had had fons on board at that time, that the idea of using a DLL rather than interrupts to truly drive the whole system would have occured to anyone in 1996-2000. Probably not, but I remember we (at Alcatel) used them in soft DSP systems at that time. But the DLL isn't really 'driving' anything, it just provides more accurate timing *information* than what you can get without it in the presence of interrupt and scheduling latencies. Most audio apps don't need this info. true, but i take it you get the way CoreAudio is doing it: it means you can drive audio processing from a different interrupt source (e.g. system timer) because you have very accurate idea of the position of the h/w frame pointer. In CoreAudio, the callback is decoupled from any PCI, USB or ieee1394 interrupt. Tasty. I actually tried to implement a similar feature quite ago (I should still have a piece of half-working code somewhere...), but I didn't merge it simply because it didn't give you better performance, only the waste of codes. Interestingly, now we have dmix and its problem with the irq timing. It might be nice to resurrect this kind of extension... Takashi
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
I agree with Rui, arts piped into jack is probably the best solution currently. And when doing paranoid low latency audio work just kill artsd as Rui said. I'm not a big user of consumer audio apps (eg mailer that emits BOING.WAV) but I guess due to certain apps being KDE centric and some GNOME centric I guess that some GNOME apps still require esd running ? What's the current coding standard for consumer audio apps that should work in both KDE and GNOME enviroments ? Use ALSA directly, support both artsd/esd etc ? I hate fragmentation and I think there should be only one audio server for consumer apps even if it's decoupled from jack (eg artsd that can output either to ALSA or to jack) but the question is who is going to give up their audio server for the competition. (eg gnome using arts) or do you think KDE and GNOME will over time agree to a common consumer audio server ? (eg this polypaudio) How does windows handle such stuff ? You simply write MME/WDM audio apps and windows applies transparent software mixing to each API ? cheers, Benno http://www.linuxsampler.org Rui Nuno Capela wrote: I guess we are in need of some guys who help making JACK ready for the desktop. If you're on KDE 3.3+, try these Setup/Options on qjackctl: [X] Execute script on Startup: `artsshell -q terminate` [X] Execute script after Startup: `artsd -F 4 -S 1024 -a jack -m artsmessage -c drkonqi -l 3 -f ` and optionally, for completeness sake: [X] Execute script on Shutdown: `artsshell -q terminate` [X] Execute script after Shutdown: `killall artsd` From then on, enjoy your jackified KDE desktop thru artsd :) Cheers.
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Hi, I guess we are in need of some guys who help making JACK ready for the desktop. If you're on KDE 3.3+, try these Setup/Options on qjackctl: [X] Execute script on Startup: `artsshell -q terminate` [X] Execute script after Startup: `artsd -F 4 -S 1024 -a jack -m artsmessage -c drkonqi -l 3 -f ` and optionally, for completeness sake: [X] Execute script on Shutdown: `artsshell -q terminate` [X] Execute script after Shutdown: `killall artsd` well, I have written a small login script which catches the ALSA ID of my USB card and starts JACK on top of it each time I login. This is because I use three USB devices and I didn't manage to index them correctly to make them appear in the same order each day. I have JACK running as soon as I log in. From then on, enjoy your jackified KDE desktop thru artsd :) Yeh, it's really cool that arts can work on top of JACK. There has been a bit of discussion before doing it on bugs.kde.org, and there also was an entry: Yep, GStreamer will output to Jack if you install Jacksink. aRts can also. So the desktop guys can keep any soundserver as long as it is able to play through JACK. Best regards ce
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
What's the current coding standard for consumer audio apps that should work in both KDE and GNOME enviroments ? Use ALSA directly, support both artsd/esd etc ? that's the problem. Currently there's no standard, but creating one would simplify life a lot for developers of any kind of audio output as well as for the BOING.WAV users. Currently a developer who wants to make an application straightforward needed various output plugins (OSS ALSA direct access, esd, arts, gstreamer and JACK). Then an autodetection needed to be added which checks for the most suitable output plugin. No developer will do this, because it's very much work. BTW: For me ALSA direct access (and therefore blocking the device) seems to be a bit ugly for a multitasking and multi user operating system like linux is. Is ALSA direct access really an option (regardless that DMIX can help with this)? An desktop independent soundserver available on each linux machine could help a lot. JACK could be a possible solution. I hate fragmentation and I think there should be only one audio server for consumer apps even if it's decoupled from jack (eg artsd that can output either to ALSA or to jack) As soon as there was an auto detection, OK. But still I'd prefer a common soundserver for all applications and window managers. but the question is who is going to give up their audio server for the competition. (eg gnome using arts) or do you think KDE and GNOME will over time agree to a common consumer audio server ? (eg this polypaudio) arts will soon be dropped and AFAIK both major desktops are looking for a common replacement. Gstreamer is one of the candidates. Best regards ce
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Sat, 2005-06-18 at 11:02 +0200, Benno Senoner wrote: How does windows handle such stuff ? You simply write MME/WDM audio apps and windows applies transparent software mixing to each API ? No, on Windows pro apps use ASIO and consumer apps use MME/DirectX. Lee
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Fri, 2005-06-17 at 18:09 +0200, Christoph Eckert wrote: ALSA direct access is no choice because it blocks the device. DMIX is a choice, but what if I want to use JACK simultaneously without using DMIX? This question amounts to how do I block the device without blocking the device. You can't do this with any OS. Lee
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
This question amounts to how do I block the device without blocking the device. You can't do this with any OS. Sorry, this was caused by my bad english skills. I'll try anew. Waht I really meant was: * We all agree that we don't want JACK to use on top of DMIX, we want JACK to run directly on top of the ALSA driver * As soon as we run JACK directly on top of the ALSA driver of a card which cannot do hardware mixing (and many many cards cannot) the card is blocked by JACK * If so and we want to achieve straightforwardness for any audio, regardless if it were bells and whistles of desktop applications or a softsynth, then all audio output needs to be passed through JACK * If so, this means that the optimal solution (5 years ahead) would be to have JACK running on any distro per default * We all know that this still needs a lot or work to be done, but if we would agree that this could be a cool solution then this would already be a great progress I do not expect that anyone of us is interested in working on such a solution. But I want to be able to tell all others That's the solution which is known to be the best by all LA* people. I try to help that linux can become the best operating system ever. I personally can perfectly deal with todays audio software, but it did last a very long time until I was able to understand the system and to control the system. I'd like to see future generations simply use all the wonderful free software we have to offer instead of still struggling with the audio subsystem a lot as we all did and do. Best regards ce
RE: What Parts of Linux Audio Simply Work Great? (was Re:[linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
windows applies transparent software mixing to each API ? No, on Windows pro apps use ASIO and consumer apps use MME/DirectX. Lee Not entirely true, Sonar achieves very nice solid latencies with WDM and MME drivers (both of which are used for consumer purposes as well). Best wishes, Ico
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Fri, Jun 17, 2005 at 12:33:20AM +0100, Damon Chaplin wrote: Out of interest, what APIs do you think GNOME and KDE should provide for sound? None. Why should a window manager / desktop provide its own API for such things ? -- FA
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Le 17 juin 05 01:51, Jay Vaughan a crit : Maybe the timers used aren't precise enough for this.. I don't know. Anyone? coreaudio does dynamic re-sampling of its 'common feed-pool' ring- buffer for audio i/o, so maybe this delay compensation is factored in that calculation? I think coreaudio does not do resampling in the HAL directly but at a upper level. There is a generic AudioUnit called AudioConverter that can do all kind of stream manipulations (interleave/deinterleave, resampling, channels mapping) and the applications are supposed to put between the HAL API and their own IO proc. AudioConverters are altivec optimized on G4 and quite fast even on G3: for example the interleave/deinterleave code is at least 2 times faster compared to what one would write with a standard loop. They can also use a AudioUnit called AUHal that internally uses AudioConverter to address the real driver. A lot of applications now this AUHal layer that simplify the job of going from the format, sampling rate... the application wants on what the choosen real driver can do. The coreaudio driver inside jackosx uses this AUHal audiounit for example. Stephane multiple clients with independent sample-rates/bit-formats can be doing their thing in OSX, a nice and good thing in my opinion (means you can have very small soundfiles for very small events while also doing the whole dvd dolby/5.1 thing at the same time) .. and i have not seen latency issues yet, except for maybe poorly written USB-audio drivers, here and there .. of course, there are tons of DAW's on OSX who don't necessarily use CoreAudio extensively yet, but there are a few OSX-native (not a port) apps that can demonstrate CoreAudio doing the work (intuem, etc.) i know its fast for what its doing, this re-sampling business.. at least on my powerbook .. altivec? i've got tons of RAM too, though, maybe thats got at least something to do with it .. ermm, maybe thats not so technical, but i can say that OSX' approach of the kernel doing the monkey business around a common API-bound ring- buffer while all apps are in sync seems to have delivered the goods .. -- ; Jay Vaughan
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Fri, 2005-06-17 at 09:57 +0200, Alfons Adriaensen wrote: On Fri, Jun 17, 2005 at 12:33:20AM +0100, Damon Chaplin wrote: Out of interest, what APIs do you think GNOME and KDE should provide for sound? None. Why should a window manager / desktop provide its own API for such things ? GNOME KDE are complete development platforms, so they need to support the development of audio applications. I'm not saying they should develop new libraries. Just that they need to standardize on particular APIs/libraries that all work together OK. (I think both GNOME KDE are considering switching audio APIs at the moment, so now is a good time for the linux-audio community to get involved.) Damon
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Fri, Jun 17, 2005 at 12:48:11PM +0100, Damon Chaplin wrote: On Fri, 2005-06-17 at 09:57 +0200, Alfons Adriaensen wrote: On Fri, Jun 17, 2005 at 12:33:20AM +0100, Damon Chaplin wrote: Out of interest, what APIs do you think GNOME and KDE should provide for sound? None. Why should a window manager / desktop provide its own API for such things ? GNOME KDE are complete development platforms, so they need to support the development of audio applications. 1. You don't need GNOME or KDE support to develop audio applications any more than you need their support for accessing files, the network, the display or whatever. So they should remain neutral on this matter. 2. Any application that can run only under a particular window manager or that depends on facilities from a particular desktop is IMHO just broken. The choice of window manager / desktop belongs to the user, not the developer. (I think both GNOME KDE are considering switching audio APIs at the moment, so now is a good time for the linux-audio community to get involved.) If everybody would just use ALSA for general use, and JACK for serious music / sound applications, that would be fine. The last thing we need is one more 'sound server / daemon'. (*) -- FA (*)rantmode A few days ago I kicked up Rosegarden again to see if it could be useful for the project I was starting. It wasn't so I terminated it, only to find out later that there were still a number of KDE applications running, including a sound daemon, blocking access to all others. Grrr. /rantmode
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Hi, 1. You don't need GNOME or KDE support to develop audio applications any more than you need their support for accessing files, the network, the display or whatever. So they should remain neutral on this matter. I absolutely agree. But why did they start to use arts/esound/gstreamer? Because they wanted to ensure that multiple applications can play sounds at the same time. What chance did they have to use a commonly accepted soundserver? None. There was no soundserver and no softwaremixing, and less people had (and still have) an audio card with hardwaremixing. 2. Any application that can run only under a particular window manager or that depends on facilities from a particular desktop is IMHO just broken. The choice of window manager / desktop belongs to the user, not the developer. Yep. (I think both GNOME KDE are considering switching audio APIs at the moment, so now is a good time for the linux-audio community to get involved.) If everybody would just use ALSA for general use, and JACK for serious music / sound applications, that would be fine. The last thing we need is one more 'sound server / daemon'. (*) Agreed. arts isn't maintained anymore, so KDE is looking for a replacement (like gstreamer). Because there's no common soundserver for all applications, they will need to make a decicion. Which audio subsystem should they support? ALSA direct access is no choice because it blocks the device. DMIX is a choice, but what if I want to use JACK simultaneously without using DMIX? JACK could become a common audio server but still it isn't. Any recommendation which audio system a programmer should use? (*)rantmode A few days ago I kicked up Rosegarden again to see if it could be useful for the project I was starting. It wasn't so I terminated it, only to find out later that there were still a number of KDE applications running, including a sound daemon, blocking access to all others. Grrr. Welcome in the Linux audio world ;-) . BTW: Arts has a timeout mode so it'll free the device as soon it isn't needed for more than the entered time. Thanks best regards ce
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Hi Christoph, On Fri, 2005-06-17 at 18:09 +0200, Christoph Eckert wrote: 1. You don't need GNOME or KDE support to develop audio applications any more than you need their support for accessing files, the network, the display or whatever. So they should remain neutral on this matter. I absolutely agree. But why did they start to use arts/esound/gstreamer? GStreamer is not a sound server. It is more like Windows' DirectShow, or Quicktime in MacOS. Regards, -- Andy Wingo http://wingolog.org/
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Hallo, Alfons Adriaensen hat gesagt: // Alfons Adriaensen wrote: On Fri, Jun 17, 2005 at 12:48:11PM +0100, Damon Chaplin wrote: GNOME KDE are complete development platforms, so they need to support the development of audio applications. 1. You don't need GNOME or KDE support to develop audio applications any more than you need their support for accessing files, the network, the display or whatever. So they should remain neutral on this matter. 2. Any application that can run only under a particular window manager or that depends on facilities from a particular desktop is IMHO just broken. ... like Ardour, which requires Jack instead of working with Arts or Esound. I think, that you're a bit unfair in regard to desktop environments. What about the role, sound can play in the accessibility of desktops, by giving acoustic feedback? We pro audio guys hate these bells and chimes, but to other users they can be important, and somehow you need some way to send these sounds from a Gonme/KDE app using Gnome/KDE libs to the soundcard, preferably in a simple, consistent way for application developers. Or go the other way around: Speech recognition. The users talks, X-Wordoffice writes it down. This is not that uncommon anymore in the Win/Mac world, and it also requires the application developer to deal with sound input *and* you need to get it into the desktop's document layer. Preferably Gnome/KDE make it easy to get to this sound with their own libraries. Sound plays a major role on desktop machines, and Novell/Suse surely is not sponsoring ALSA for us musicians, they want to get sound on desktops. The best of course would be a solution, which works accross all desktops and non-desktops. But this would require all applications to be broken in the regard, that all these apps should support at least this solution. Ciao -- Frank Barknecht _ __footils.org__ _ __latest track: scans _ http://footils.org/cms/show/41
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Friday 17 Jun 2005 14:24, Alfons Adriaensen wrote: A few days ago I kicked up Rosegarden again to see if it could be useful for the project I was starting. It wasn't so I terminated it, only to find out later that there were still a number of KDE applications running, including a sound daemon, blocking access to all others. Grrr. I can sympathise with that. Rosegarden itself doesn't use or want the KDE sound daemon, so it's rather counterproductive that KDE likes to start it anyway. Chris
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Fri, Jun 17, 2005 at 06:09:52PM +0200, Christoph Eckert wrote: Which audio subsystem should they support? ALSA direct access is no choice because it blocks the device. DMIX is a choice, but what if I want to use JACK simultaneously without using DMIX? Is that realistic ? Would you do any serious audio work and leave all the desktop toys enabled *on the same card* ? (I don't have any 'desktop' sounds, so for me it's easy :-) JACK could become a common audio server but still it isn't. Any recommendation which audio system a programmer should use? For any serious music and audio software there is (for me) just one answer: JACK, and maybe also ALSA. For all the rest I think ALSA's dmix device is the right solution. -- FA
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Fri, Jun 17, 2005 at 06:58:18PM +0200, Frank Barknecht wrote:
... like Ardour, which requires Jack instead of working with Arts or
Esound.
JACK is not part of any desktop system. It's absolutely neutral in
this sense, _and_ designed to support 'professional' audio. For a
tool like Ardour, I don't think there any other choice.
I think, that you're a bit unfair in regard to desktop environments.
What about the role, sound can play in the accessibility of desktops,
by giving acoustic feedback? We pro audio guys hate these bells and
chimes, but to other users they can be important, and somehow you need
some way to send these sounds from a Gonme/KDE app using Gnome/KDE
libs to the soundcard, preferably in a simple, consistent way for
application developers.
Or go the other way around: Speech recognition. The users talks,
X-Wordoffice writes it down. This is not that uncommon anymore in the
Win/Mac world, and it also requires the application developer to deal
with sound input *and* you need to get it into the desktop's document
layer. Preferably Gnome/KDE make it easy to get to this sound with
their own libraries.
Valid points, and you even forgot VoIP.
The best of course would be a solution, which works accross all
desktops and non-desktops. But this would require all applications to
be broken in the regard, that all these apps should support at least
this solution.
I think we should (and can) keep the desktop and 'pro' worlds separate.
And if they have to be integrated, the solution will be JACK. Writing
a JACKified app is not harder (rather the contrary) than for any other
API I know. There could be some libs on top of JACK to make the common
things such as bells and chimes even simpler {jack_play(boing.wav);}.
The only condition is that jackd should be 100% reliable and monkey-proof,
but I think it's already quite close to that target.
I remember that when I started using Linux (SL 8.1) JACK was quite
a hairy thing to have on you system, and a few months later at the first
LAC, there were lots of killall jackd all the time. And now ? When my
desktop comes up qjackctl starts running, and it stays there for as long
as the system is up.
--
FA
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Hallo, fons adriaensen hat gesagt: // fons adriaensen wrote: On Fri, Jun 17, 2005 at 06:58:18PM +0200, Frank Barknecht wrote: ... like Ardour, which requires Jack instead of working with Arts or Esound. JACK is not part of any desktop system. It's absolutely neutral in this sense, _and_ designed to support 'professional' audio. For a tool like Ardour, I don't think there any other choice. Well, I don't really want to discuss Jack's merits (we all know them). I just wanted to point out, that one might consider Jack to be a kind of pro audio desktop. It does much of the same things for audio, that Gnome/KDE do for desktops: Provide a common API, abstract concepts from hardware, let applications work together in convenient ways, it provides system configuration and session management hooks (used by things like qjackctl) etc. If one thinks about Gnome/KDE from the perspective of how we benefit of Jack, then some of the choices, the G/KDE developers faced and tried to solve, might become more understandable. They actually are working on a much bigger problem than we, I guess, let alone because they have to support many more users. Ciao -- Frank Barknecht _ __footils.org__ _ __latest track: scans _ http://footils.org/cms/show/41
Audio APIs GNOME KDE (was Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?))
Damon Chaplin wrote: GNOME KDE are complete development platforms, so they need to support the development of audio applications. I'm not saying they should develop new libraries. Just that they need to standardize on particular APIs/libraries that all work together OK. (I think both GNOME KDE are considering switching audio APIs at the moment, so now is a good time for the linux-audio community to get involved.) Have you considered Polypaudio: http://0pointer.de/lennart/projects/polypaudio/ The Ubuntu people are looing at replacing ESD with this one. In their scheme, Polypaudio would use ALSA's dmix rather than direct ALSA. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ There is no reason why anyone would want a computer in their home Ken Olson, DEC, 1977
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Which audio subsystem should they support? ALSA direct access is no choice because it blocks the device. DMIX is a choice, but what if I want to use JACK simultaneously without using DMIX? Is that realistic ? Would you do any serious audio work and leave all the desktop toys enabled *on the same card* ? not for me. We both know how to handle audio subsystems, and I have disabled arts completely. And I'm using the onboard sound for viewing news videos and the USB card for all of my audio work. But what about users who aren't that experienced? They simply expect that audio output works transparently. If a card doesn't support hardware mixing (and most consumer cards don't) they will still have to struggle with the soundsystem except there's one solution. (I don't have any 'desktop' sounds, so for me it's easy :-) I also dislike desktop sounds, but there are users who don't care or who like it. Well, we both agree that it makes less sense listening to an ardour session while a MUA plays a silly sound when a mail drops in... JACK could become a common audio server but still it isn't. Any recommendation which audio system a programmer should use? For any serious music and audio software there is (for me) just one answer: JACK, and maybe also ALSA. For all the rest I think ALSA's dmix device is the right solution. DMIX will help a lot. But is it really necessary to divide the users in pro users and consumer users? Theoretically: no. Theoretically there's a solution: JACK needs to be the one and only soundserver for all purposes. BUt we aren't there yet. And I do not want to recall my earlier thread Common unix audio layer ;-) . Best regards ce
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
I guess we are in need of some guys who help making JACK ready for the desktop. If you're on KDE 3.3+, try these Setup/Options on qjackctl: [X] Execute script on Startup: `artsshell -q terminate` [X] Execute script after Startup: `artsd -F 4 -S 1024 -a jack -m artsmessage -c drkonqi -l 3 -f ` and optionally, for completeness sake: [X] Execute script on Shutdown: `artsshell -q terminate` [X] Execute script after Shutdown: `killall artsd` From then on, enjoy your jackified KDE desktop thru artsd :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED]
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Wed, Jun 15, 2005 at 08:22:17AM -0400, Paul Davis wrote: i don't think thats entirely fair. when jaroslav started ALSA i think he was intent on a set of ideas that looked like the best choices at the time. the goal was to improve lots of issues with OSS, including its requirement for all functionality to reside in the kernel. And that was an excellent step. i don't think that, even if we had had fons on board at that time, that the idea of using a DLL rather than interrupts to truly drive the whole system would have occured to anyone in 1996-2000. Probably not, but I remember we (at Alcatel) used them in soft DSP systems at that time. But the DLL isn't really 'driving' anything, it just provides more accurate timing *information* than what you can get without it in the presence of interrupt and scheduling latencies. Most audio apps don't need this info. as for callbacks, this would have been dismissed by almost all commentators because it would require every single existing audio app to be rewritten. it would have been a great idea, yes, but it would never have been accepted. too many developers would have whined to LKML that it was unacceptable to remove the open/read/write/close model from the official linux audio API. There is nothing really wrong with that model per se, and you can easily build a callback system on top of it, as jackd does. Basically all it requires is a user-space thread to call back from. I think the real reason why such a callback (to user space) system was probably impossible at the time is that it can't be done without user space threading, or at least some form of co-routines. How many people were prepared to write multi-threaded apps in 1995, if it could be done at all ? For most of us in this group it seems like a natural thing to do, but I'm sure that even today the whole concept of multithreading and message or event driven programming remains something quite unfamiliar to the majority of programmers, -- FA
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
i don't think that, even if we had had fons on board at that time, that the idea of using a DLL rather than interrupts to truly drive the whole system would have occured to anyone in 1996-2000. Probably not, but I remember we (at Alcatel) used them in soft DSP systems at that time. But the DLL isn't really 'driving' anything, it just provides more accurate timing *information* than what you can get without it in the presence of interrupt and scheduling latencies. Most audio apps don't need this info. true, but i take it you get the way CoreAudio is doing it: it means you can drive audio processing from a different interrupt source (e.g. system timer) because you have very accurate idea of the position of the h/w frame pointer. In CoreAudio, the callback is decoupled from any PCI, USB or ieee1394 interrupt. Tasty. developers would have whined to LKML that it was unacceptable to remove the open/read/write/close model from the official linux audio API. There is nothing really wrong with that model per se, and you can easily build a callback system on top of it, as jackd does. you can, true, though JACK doesn't. JACK uses poll and mmap (the OSS driver uses ioctls and select IIRC); expecting regular audio developers to use poll/mmap on a day to day basis creates very bad reactions :) --p
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
true, but i take it you get the way CoreAudio is doing it: it means you can drive audio processing from a different interrupt source (e.g. system timer) because you have very accurate idea of the position of the h/w frame pointer. In CoreAudio, the callback is decoupled from any PCI, USB or ieee1394 interrupt. Tasty. .. yes, very tasty. the performance-enhancin OS-provided ring-buffer/sample-rate convertor that this allows is also, of course, tasty. you can, true, though JACK doesn't. JACK uses poll and mmap (the OSS driver uses ioctls and select IIRC); expecting regular audio developers to use poll/mmap on a day to day basis creates very bad reactions :) it only has to be done right once, though, and from that point on, wrapped in an API and well-promoted as a black-box handling for audio i/o. -- ; Jay Vaughan
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Thu, Jun 16, 2005 at 10:30:29AM -0400, Paul Davis wrote: true, but i take it you get the way CoreAudio is doing it: it means you can drive audio processing from a different interrupt source (e.g. system timer) because you have very accurate idea of the position of the h/w frame pointer. In CoreAudio, the callback is decoupled from any PCI, USB or ieee1394 interrupt. Tasty. Didn't know they were doing that. But what is gained this way ? The interrupt latency (probably less) and scheduling delays are still there. I once had a look at the CoreAudio code in SC3. It's in the same file as the jack interface, and both have similar code to implement some sort of DLL-like smoothing. Any advantage CoreAudio has is certainly not visible in that file. And when the jack version is rewritten to use the second DLL (using OSC time) I'll be proposing, it will be much simpler than the CoreAudio interface. It could even by done using the current (frame time) DLL, with some complications. There is nothing really wrong with that model per se, and you can easily build a callback system on top of it, as jackd does. you can, true, though JACK doesn't. JACK uses poll and mmap I know, but would there be much difference between poll()/mmap() and read()/write() if you look at what happens internally ? The read()/write() calls combine the actions of waiting, probably using the same mechanisms as poll(), with a data copy to or from a user provided buffer. The latter you do yourself when using poll()/mmap(). Both systems are the same in the sense that for both, the user waits for the driver. expecting regular audio developers to use poll/mmap on a day to day basis creates very bad reactions :) Where are all those real programmers ? ;-) -- FA
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Thu, 16 Jun 2005 10:30:29 -0400 Paul Davis [EMAIL PROTECTED] wrote: true, but i take it you get the way CoreAudio is doing it: it means you can drive audio processing from a different interrupt source (e.g. system timer) because you have very accurate idea of the position of the h/w frame pointer. In CoreAudio, the callback is decoupled from any PCI, USB or ieee1394 interrupt. Tasty. The price for this is afaik an extra period worth of latency. I'm not sure this is the way to go. Sure it makes handling of devices easier that do not generate irq's like pci soundcards do (all this USB and IEEE1394 stuff), but isn't the price too high? Flo -- Palimm Palimm! http://affenbande.org/~tapas/
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Thu, Jun 16, 2005 at 05:59:09PM +0200, Florian Schmidt wrote: On Thu, 16 Jun 2005 10:30:29 -0400 Paul Davis [EMAIL PROTECTED] wrote: true, but i take it you get the way CoreAudio is doing it: it means you can drive audio processing from a different interrupt source (e.g. system timer) because you have very accurate idea of the position of the h/w frame pointer. In CoreAudio, the callback is decoupled from any PCI, USB or ieee1394 interrupt. Tasty. The price for this is afaik an extra period worth of latency. I'm not sure this is the way to go. Sure it makes handling of devices easier that do not generate irq's like pci soundcards do (all this USB and IEEE1394 stuff), but isn't the price too high? Why should this take a extra period of latency ? -- FA
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Thu, 16 Jun 2005 20:20:41 +0200 fons adriaensen [EMAIL PROTECTED] wrote: The price for this is afaik an extra period worth of latency. I'm not sure this is the way to go. Sure it makes handling of devices easier that do not generate irq's like pci soundcards do (all this USB and IEEE1394 stuff), but isn't the price too high? Why should this take a extra period of latency ? Ah, i remembered slightly incorrectly. Thanks Paul, for setting me straight in #ardour. The thing is that the DLL based client thread wakeup has the ever so slight possibility to do its thing too early. Thus coreaudio waits a bit more (the safety offset). It seems this safety offset is driver specific but usually ranges from 64 to 32 frames (i have no definite source for this, just a bit of googling). And with a sufficiently low period size used this accounts for pretty much an extra period of latency.. Flo -- Palimm Palimm! http://affenbande.org/~tapas/
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Thu, Jun 16, 2005 at 10:57:51PM +0200, Florian Schmidt wrote: Ah, i remembered slightly incorrectly. Thanks Paul, for setting me straight in #ardour. The thing is that the DLL based client thread wakeup has the ever so slight possibility to do its thing too early. Thus coreaudio waits a bit more (the safety offset). It seems this safety offset is driver specific but usually ranges from 64 to 32 frames (i have no definite source for this, just a bit of googling). And with a sufficiently low period size used this accounts for pretty much an extra period of latency.. Strange... If you would program a timer using the info available from jackd's DLL, it would never generate its interrupt before the HW is ready (i.e. has at least a period available). It would actually trigger just after the interrupt it is derived from (the small average latency that is not compensated). So I wonder what problem CoreAudio has with this. -- FA
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Thu, 16 Jun 2005 23:54:01 +0200 fons adriaensen [EMAIL PROTECTED] wrote: Strange... If you would program a timer using the info available from jackd's DLL, it would never generate its interrupt before the HW is ready (i.e. has at least a period available). It would actually trigger just after the interrupt it is derived from (the small average latency that is not compensated). So I wonder what problem CoreAudio has with this. Maybe the timers used aren't precise enough for this.. I don't know. Anyone? Flo -- Palimm Palimm! http://affenbande.org/~tapas/
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-06-14 at 11:50 -0400, Paul Davis wrote: but more broadly, windows is not the gold standard here, OS X is, and the truth is that apple have designed a much better system from day one. on OS X, things do work more or less the way jwz and many other people think they should. JACK gets close, and in a few ways (inter-app connectivity) betters CoreAudio, but it is not a general purpose audio API and there are no whipmasters to force mplayer, skype, and rest of the desktop app developers to use it. Out of interest, what APIs do you think GNOME and KDE should provide for sound? It would be great to standardize on one set of APIs that provided support for both general purpose and professional quality audio apps (and all working together happily). Damon
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Maybe the timers used aren't precise enough for this.. I don't know. Anyone? coreaudio does dynamic re-sampling of its 'common feed-pool' ring-buffer for audio i/o, so maybe this delay compensation is factored in that calculation? multiple clients with independent sample-rates/bit-formats can be doing their thing in OSX, a nice and good thing in my opinion (means you can have very small soundfiles for very small events while also doing the whole dvd dolby/5.1 thing at the same time) .. and i have not seen latency issues yet, except for maybe poorly written USB-audio drivers, here and there .. of course, there are tons of DAW's on OSX who don't necessarily use CoreAudio extensively yet, but there are a few OSX-native (not a port) apps that can demonstrate CoreAudio doing the work (intuem, etc.) i know its fast for what its doing, this re-sampling business.. at least on my powerbook .. altivec? i've got tons of RAM too, though, maybe thats got at least something to do with it .. ermm, maybe thats not so technical, but i can say that OSX' approach of the kernel doing the monkey business around a common API-bound ring-buffer while all apps are in sync seems to have delivered the goods .. -- ; Jay Vaughan
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
It would be great to standardize on one set of APIs that provided support for both general purpose and professional quality audio apps (and all working together happily). Apples' API docs for CoreAudio can be found here: http://developer.apple.com/audio/pdf/coreaudio.pdf great reading, actually, i thoroughly enjoy their approach to HAL .. -- ; Jay Vaughan
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-06-14 at 20:52 -0400, Lee Revell wrote: On Tue, 2005-06-14 at 21:16 +0200, Jay Vaughan wrote: b) an [mplayer/skype] patch-fest to bring them in line with that strategy using actual source changes (where possible) Skype is closed source and the mplayer developers are a pain in the ass to deal with due to blatant pro-OSS (as in /dev/dsp) bias. If it were easy these would have been fixed long ago. Mplayer already has support for a lot of different audio interfaces (including ALSA and JACK). I don't know how good or stable it is, but I've never had any problems using them. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E signature.asc Description: This is a digitally signed message part
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Wed, Jun 15, 2005 at 11:50:11AM +0200, Lars Luthman wrote: On Tue, 2005-06-14 at 20:52 -0400, Lee Revell wrote: On Tue, 2005-06-14 at 21:16 +0200, Jay Vaughan wrote: b) an [mplayer/skype] patch-fest to bring them in line with that strategy using actual source changes (where possible) Skype is closed source and the mplayer developers are a pain in the ass to deal with due to blatant pro-OSS (as in /dev/dsp) bias. If it were easy these would have been fixed long ago. Mplayer already has support for a lot of different audio interfaces (including ALSA and JACK). I don't know how good or stable it is, but I've never had any problems using them. never worked right here, end up using the arts backend (and jack backend for arts...and alsa backend for jack...). how many chained APIs does one need? mplayer -ao jack blabla.mp3: AO: [Jack] Initialising library. MPlayer interrupted by signal 11 in module: ao2_init - MPlayer crashed by bad usage of CPU/FPU/RAM. - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Ranting on his blog just makes him look like an ass. Lee but .. thats what blogs are for. -- ; Jay Vaughan
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Wed, 2005-15-06 at 10:36 +, [EMAIL PROTECTED] wrote: On Wed, Jun 15, 2005 at 11:50:11AM +0200, Lars Luthman wrote: On Tue, 2005-06-14 at 20:52 -0400, Lee Revell wrote: On Tue, 2005-06-14 at 21:16 +0200, Jay Vaughan wrote: b) an [mplayer/skype] patch-fest to bring them in line with that strategy using actual source changes (where possible) Skype is closed source and the mplayer developers are a pain in the ass to deal with due to blatant pro-OSS (as in /dev/dsp) bias. If it were easy these would have been fixed long ago. Mplayer already has support for a lot of different audio interfaces (including ALSA and JACK). I don't know how good or stable it is, but I've never had any problems using them. never worked right here, end up using the arts backend (and jack backend for arts... and alsa backend for jack...). how many chained APIs does one need? Well, if Alsa went the CoreAudio direction and did a proper callback-based audio API ala Jack, and did s/w mixing automagically, we wouldn't need all this mess. Unfortunately, the Alsa people didn't seem to think replacing OSS was a good opportunity to improve anything, so here we are... let's hear it for 1995. -DR-
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Well, if Alsa went the CoreAudio direction and did a proper callback-based audio API ala Jack, and did s/w mixing automagically, we wouldn't need all this mess. Unfortunately, the Alsa people didn't seem to think replacing OSS was a good opportunity to improve anything, so here we are... let's hear it for 1995. i don't think thats entirely fair. when jaroslav started ALSA i think he was intent on a set of ideas that looked like the best choices at the time. the goal was to improve lots of issues with OSS, including its requirement for all functionality to reside in the kernel. i don't think that, even if we had had fons on board at that time, that the idea of using a DLL rather than interrupts to truly drive the whole system would have occured to anyone in 1996-2000. as for callbacks, this would have been dismissed by almost all commentators because it would require every single existing audio app to be rewritten. it would have been a great idea, yes, but it would never have been accepted. too many developers would have whined to LKML that it was unacceptable to remove the open/read/write/close model from the official linux audio API. apple had good fortune, good people and lots of control on their side. we have smarter people (or at least as smart), lots of good examples, but very little control. --p
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
never worked right here, end up using the arts backend (and jack backend for arts...and alsa backend for jack...). how many chained APIs does one need? mplayer -ao jack blabla.mp3: AO: [Jack] Initialising library. MPlayer interrupted by signal 11 in module: ao2_init - MPlayer crashed by bad usage of CPU/FPU/RAM. - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read AFAIK mplayer uses the bio2jack plugin[1]. Maybe you could try a newer version of it. Best regards ce [http://bio2jack.sf.net]
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-14-06 at 10:50 +0200, Jay Vaughan wrote: I must admit, I had to double-check that I really am reading the year-2005 folder of linux-audio-dev, and not some old mails from the archives. ;) Now that SuSE, Mandrake, Fedora and others have started to use dmix as the default output plugin, basic desktop sound stuff should finally start to work, as people expect, out of the box. i mean, we should take this jwz thing as a call for jihad against non-working audio, including the perception of non-working audio, and such a jihad may be best served by those examples of no-problem systems coming forward and being demo'ed. I think we should take it for what it is: a whiney rant from someone who is famous for whining about anything and everything. Why should we care what jwz thinks? Let him publicly cry and run to OSX - see if I care. Addressing the concerns of people looking for help on this list is a million times more important than some nonsense PR campaign to counter the rant of a whiney dotcom washout that happened to get slashdotted. -DR-
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
I think we should take it for what it is: a whiney rant from someone who is famous for whining about anything and everything. sorry, but i don't agree. Why should we care what jwz thinks? jwz, like it or not, leads opinion. he makes news. agree with him or disagree with him: you're still being led into an opinion on a subject as a result of his effort, either way. such opinion-cults are all the FOSS world -has- for a PR front. this one happens to be negative. its quite possible, however, that a counter to his position would work *positively*, if we were prepared to organize it a bit. i'd be quite happy, actually, to submit to /. a never mind jwz, linux audio rocks! style article which puts the actual -facts- on the table for anyone wanting to check out linux audio. blowback PR works, if timed right, and delivered properly. maybe you'll be thanking jwz in a week or two .. Let him publicly cry and run to OSX - see if I care. if we allow the falsehoods regarding linux audio to be spread by his infamy/fame, whiney or not, washed out or not, we're doing ourselves (audio hackers) a disservice. is it not poignant enough for you that the OSS guys are using the jwz attack on ALSA to pimp their way of doing things? should FOSS authors really eat themselves in such ways? screw that! just tell -me- what works, and i'll make sure folks know about it! Addressing the concerns of people looking for help on this list is a million times more important than some nonsense PR campaign to counter the rant of a whiney dotcom washout that happened to get slashdotted. look, PR is a big problem with linux audio. taking -some- degree of responsibility for it is a step to solve that. not all problems with linux audio are purely technical; mostly, it seems, its education. all good education efforts start with overt PR about the subject, presenting reasons why its worth educating oneself further .. a shiny boot-CD DAW 'That Just Works' (tm) will attract far more users than endless reams of archives describing 'how to fix things yourself'. hell, a list of known working configs from various well known individuals may just be all we need. my audio system may not work right now, but a boot-CD/list of known working systems will serve to provide hope when there may be very little. describe the working systems, promote the solutions not the problems. continually working on a 'this is broke - fix it' basis is one thing; working on a 'this works - use it' basis is another thing entirely. i happen to think the latter approach produces better results when it comes to getting people interested in fixing their tools themselves, especially when casual observers are tipped over the edge from just looking at how bad things are to active participant actually -using- the tools to do something cool because it was demonstrated that such things can be done .. jwz -does- have a point. its not the 90's. he really shouldn't have had such problems with getting his freakin' audio working. its not a technical issue; its an organizational one. counter his argument with success, and the whole scene gets turned around: suddenly, linux audio is cooler than it was a week ago. -- ; Jay Vaughan
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Hi, I have a PlanetCCRMA FC2 system on a Dell Inspiron8200 (P4 1.6G 512 ram) that works absolutely fantastic, both with the onboard AC97 card and with the pcmcia Echo Mona Interface. Latency in jack 5.4 ms very reliably (xruns ocasionally when doing something you know will cause an xrun, like when returning from the screensaver or dragging quickly many windows). They are inaudible xruns, and since I'm using my system for live processing with pd and csound5, this is no problem. I've also tried dynebolic (www.dynebolic.org) and on the two systems I've tried works considerably better than agnula live and the suse live audio cd. Cheers, Andres On Tue, 2005-06-14 at 03:50, Jay Vaughan wrote: I must admit, I had to double-check that I really am reading the year-2005 folder of linux-audio-dev, and not some old mails from the archives. ;) Now that SuSE, Mandrake, Fedora and others have started to use dmix as the default output plugin, basic desktop sound stuff should finally start to work, as people expect, out of the box. it would be great to counter the jwz diatribe with a mass of 'well, sound works just fine for me' posts from those who do have, and use daily, a working audio sub-system under linux.. perhaps folks on LAD know of sites which have a positive linux audio experience slant to them? what LAD needs, maybe, is a tiger campaign (as in PR, not OSX) to fully push the -successes- and very interesting audio stuff? i mean, we should take this jwz thing as a call for jihad against non-working audio, including the perception of non-working audio, and such a jihad may be best served by those examples of no-problem systems coming forward and being demo'ed. i've mentioned this before, but i think that the front-line promotion of such wonderment as Ardour and Audacity and Rosegarden needs BOOT CD-style .iso downloads for the pimps to use in overcoming peoples 'fear of linux audio'. if i can just boot a system on a very well configured distro and immediately start using Ardour from it, it won't matter what the config hassles are, later, once i decide to build my own Linux Audio Workstation: i'll have a standard to compare to Which Just Works (tm). (i know about the Apodio and Demudi efforts.. so what else are there?) i'm sure there are LAD'ers whose systems are superlative examples of well-oiled, finely maintained, working audio workstations. what are your configs? what distro are you using? what do you do to get it going? maybe the fact is: linux audio is in far better state than most people think, its just that hardly enough of the right kinds of people know about it. jwz doing his soapbox thing could be considered destructive in such light, and in fact we may use this to our advantage to really pimp linux audio, if we have the organized -facts- and not just feelings.. my latest distro-de-jour is MEPIS. it gives me a boot-up chime on my DELL Inspiron 8200, whose sound-card 'just works', tho' i have to be sure not to have any MIDI interfaces or USB Audio gear plugged in until after KDE gets loaded, or things get numbered incorrectly and it moans about not knowing where its audio device is any more. Details like configuring dmix and other plugins, making sure the aoss-wrapper is used with OSS apps, etc are important... as i've only really been very peripherally involved in LAD development (lurk), i'd be quite happy to volunteer to collate all the successes and come up with a summary of 'what works well' to pimp around the neighborhood. i work in the pro audio industry, it'd sure be nice to have a collection of boot CD's that i can take, know that work, and slip into an occasional demo system now and then .. and not just one authoritative CD experience, but a few others from various sources. nothing says 'working just fine' more than multiple distro's all singing the same tune. As for the API-jungle, yup, that's a problem, but it's something really, really hard to avoid in the FOSS world. Just look at the amount of options for video output when you type mplayer -vo help -- no unified API there either. That's not to say that we should give up, but getting majority of developers behind a single API will not be easy... a lot of times i think that the API mess happens because those who wrote great API's don't promote them well enough, new folks come looking for similar scratches to itch, don't see behind the curtain, and thus re-invent their own wheels. itches, curtains and wheels. all good for something, but the fat lady hasn't sung yet. But, but, this is just part of the whole package developers and users see. Fortunately there are other areas where FOSS systems have strengths over the closed competitors. And at least for me, FOSS systems still provide better overall value... (also for desktop use). for me too, in fact my life has revolved around using FOSS-based
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-06-14 at 11:27 +0200, Jay Vaughan wrote: jwz, like it or not, leads opinion. he makes news. agree with him or disagree with him: you're still being led into an opinion on a subject as a result of his effort, either way. Who in the hell is this jwz, and why does everyone care what he thinks so much? Can someone at least post a link to this rant of his? Lee
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Am Dienstag, den 14.06.2005, 10:36 -0400 schrieb Lee Revell: Who in the hell is this jwz, and why does everyone care what he thinks so much? Can someone at least post a link to this rant of his? This one? jwz - fuck the skull of alsa http://jwz.livejournal.com/490051.html
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 14 Jun 2005, Jan Weil wrote: Am Dienstag, den 14.06.2005, 10:36 -0400 schrieb Lee Revell: Who in the hell is this jwz, and why does everyone care what he thinks so much? Can someone at least post a link to this rant of his? This one? jwz - fuck the skull of alsa http://jwz.livejournal.com/490051.html Hmmm... interesting... still, who is this guy? I've been using Linux audio since like 1997, yeah, I ran into a few issues back then (I had a Turtle Beach San Tropez card), but have used several varieties of SB through OSS and ALSA, and currently have one machine using SBLive! + ALSA (my graphics workstation) and another machine using M-Audio 2496 + ALSA + Jack + realtime patches (my DAW), and audio has always just worked. I build my own kernels and ALSA drivers, so maybe that's it? *shrug* I've had audio issues on Windows plenty of times also, including one machine that dual-booted Linux Windows... Red Hat detected my video and sound on first installation and everything just worked and on Windows (same machine), I had to install some drivers manually because the autodetection failed. Oh well. -- Brett
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-06-14 at 17:12 +0200, Jan Weil wrote: Am Dienstag, den 14.06.2005, 10:36 -0400 schrieb Lee Revell: Who in the hell is this jwz, and why does everyone care what he thinks so much? Can someone at least post a link to this rant of his? This one? jwz - fuck the skull of alsa http://jwz.livejournal.com/490051.html Also, he seems to be pissed because he bought one of the new SBLives that uses the snd-ca0106 driver, and expects to get hardware mixing like a real SBLive. He's just an idiot, and his beef is with Creative, not the ALSA people. Lee
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-06-14 at 17:12 +0200, Jan Weil wrote: Am Dienstag, den 14.06.2005, 10:36 -0400 schrieb Lee Revell: Who in the hell is this jwz, and why does everyone care what he thinks so much? Can someone at least post a link to this rant of his? This one? jwz - fuck the skull of alsa http://jwz.livejournal.com/490051.html That's it? Why do people listen to this guy again, he seems to be just another idiot luser who blames ALSA for every XMMS bug. Lee
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Hi, Why not solve this kinds of problems. Soulutions: 1) Remove OSS drivers from kernel - then all problems will be alsa problems. 2) Remove OSS emulation from alsa - then all problems will be OSS problems. Otherways this will be newer end. Peter Zubaj ___ Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete. http://www.wanda.sk/
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Also, he seems to be pissed because he bought one of the new SBLives that uses the snd-ca0106 driver, and expects to get hardware mixing like a real SBLive. He's just an idiot, and his beef is with Creative, not the ALSA people. jwz isn't an idiot, and he doesn't expect h/w mixing. he knows the difference between h/w and s/w mixing. his point is that from a desktop perspective, linux in 2005 ought to just provide [hs]/w mixing as required, with no intervention by the (desktop) user. he's not talking about musicians, or other creative acoustic types. he's right. what jwz doesn't understand is the limited hw vendor support audio devices get (chipsets changing subtly at random times, undocumented pinouts, lack of adherence to ac97 or other standards). he also doesn't understand how few people produced ALSA. and most of all he doesn't realize the design tradeoffs between the various audio APIs. he's the guy who would have been very happy with the windows kernel mixer-based audio API, and would have known absolutely nothing about why people needed ASIO, GSIF etc. but more broadly, windows is not the gold standard here, OS X is, and the truth is that apple have designed a much better system from day one. on OS X, things do work more or less the way jwz and many other people think they should. JACK gets close, and in a few ways (inter-app connectivity) betters CoreAudio, but it is not a general purpose audio API and there are no whipmasters to force mplayer, skype, and rest of the desktop app developers to use it. --p
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-06-14 at 11:50 -0400, Paul Davis wrote: Also, he seems to be pissed because he bought one of the new SBLives that uses the snd-ca0106 driver, and expects to get hardware mixing like a real SBLive. He's just an idiot, and his beef is with Creative, not the ALSA people. jwz isn't an idiot, and he doesn't expect h/w mixing. he knows the difference between h/w and s/w mixing. his point is that from a desktop perspective, linux in 2005 ought to just provide [hs]/w mixing as required, with no intervention by the (desktop) user. he's not talking about musicians, or other creative acoustic types. he's right. I've said it before and I'll say it again, this is a distro problem. We all know it can be made to work, so it should be a simple matter of automating the process. Don't they test this stuff before they ship? For example dmix has been available for quite some time, but no distro enabled it by default, even though users clearly want it. Now that ALSA uses it by default, all of a sudden, all the distros use it by default, and they're hyping it as some shiny new feature. Aren't the distros supposed to drive the adoption of new features, due to their proximity to users? We're in bad shape if all they do is wait for the developers to respond to user needs. This all tells me that the distro maintainers put a shockingly low priority on having sound work OOTB, otherwise, why didn't they do this a year ago? AFAICT it's just laziness. Lee
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
it would be great to counter the jwz diatribe with a mass of 'well, sound works just fine for me' posts from those who do have, and use daily, a working audio sub-system under linux.. We aren't there - not yet. [...] i'm sure there are LAD'ers whose systems are superlative examples of well-oiled, finely maintained, working audio workstations. what are your configs? what distro are you using? what do you do to get it going? Still it's a bit difficult to set up a pro audio system because it needs kernel patching and various configuration work. As for the kernel patches we're optimistic to get a realtime patch in the vanilla kernel sooner or later. As for the configuration work we could need a replacement for alsaconf (which has done a great job in the past) called audioconf to configure cards, realtime patches and creating a JACK configuration file. maybe the fact is: linux audio is in far better state than most people think, It is. its just that hardly enough of the right kinds of people know about it. I know about it, that's enough for me :) . my latest distro-de-jour is MEPIS. it gives me a boot-up chime on my DELL Inspiron 8200, whose sound-card 'just works', tho' i have to be sure not to have any MIDI interfaces or USB Audio gear plugged in until after KDE gets loaded, or things get numbered incorrectly and it moans about not knowing where its audio device is any more. I also use the i82k. As for the USB card numbering, you can index your card. What's missing is auto-configuration to avoid manual work for common users, or at least a configuration help for unexperienced users, may it be CLI or GUI. You're invited to contribute ;-) . as i've only really been very peripherally involved in LAD development (lurk), i'd be quite happy to volunteer to collate all the successes and come up with a summary of 'what works well' to pimp around the neighborhood. If I were you I'd cancel this offer. Otherwise we'll meet again in five years and you will not be finished yet ;-) . Frankly, save your time and better help us improving linux audio if you like. We have addressed several weak points in this thread, so there are many good starting points. Otherwise, all the characters of this thread have been temps perdu. [...] so, the question i have is: what are the shining examples of audio setups in linux which work well? might it be something we can make a list out of, and pimp far and wide? who has some interesting Known Working Config details to provide a counter-example to the jwz mess? * Take a Distro (I use Gentoo and I'm just happy with it) * Stop all desktop soundservers * Start JACK * Start [Rosegarden|Hydrogen|ams|Zyn|Ardour|any other fun toy] * Enjoy Best regards ce
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
This all tells me that the distro maintainers put a shockingly low priority on having sound work OOTB, otherwise, why didn't they do this a year ago? AFAICT it's just laziness. Laziness and commercial pressure. The commercial distros spend their time in patching kernels, creating distro dependent configuration front ends and adjusting the desktops. They do not spend time to adjust all software packages, and so they often take the packages as downloaded from the web. Best regards ce
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
That's it? Why do people listen to this guy again, he seems to be just another idiot luser who blames ALSA for every XMMS bug. ever heard of netscape? jwz is one of the glory-children of that project, a very active F/OSS advocate over the years. this story is important because it is about advocacy, good and bad. -- ; Jay Vaughan
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
he [jwz] also doesn't understand how few people produced ALSA. i dunno, i don't want to speak for jwz, but i'm pretty sure he's aware just how a few people can get a very great thing done. you may say he's seasoned at it, in fact, and knows the pitfalls 'the mob' go through in order to get themselves organized and avoid stagnancy .. at least, as a reader of his frequent rants for the past 15 years now on the topic of OSS/software development, thats the sense i get. but more broadly, windows is not the gold standard here, OS X is, and the truth is that apple have designed a much better system from day one. i would like to point out that both ALSA and CoreAudio have similar lifecycles, too. i mean, i don't think CoreAudio got a lot of its heritage from the NextStep days (though NS had bitchin' audio from the beginning, also), but there is a great deal to be thought about in comparing the two approaches. on OS X, things do work more or less the way jwz and many other people think they should. JACK gets close, and in a few ways (inter-app connectivity) betters CoreAudio, but it is not a general purpose audio API and there are no whipmasters to force mplayer, skype, and rest of the desktop app developers to use it. i think a combination of: a) a well-formed strategy to clean up the Linux mess, and b) an [mplayer/skype] patch-fest to bring them in line with that strategy using actual source changes (where possible), and c) far greater advocacy of the success of linux audio by its users and boot-CD makers .. ... would do the job. oh, and i guess it wouldn't hurt to have a macmusic.org-like linuxaudioapps.org clone around, too, though i know there are already a few sites perilously qualified for this slot .. -- ; Jay Vaughan
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
a) a well-formed strategy to clean up the Linux mess, and b) an [mplayer/skype] patch-fest to bring them in line with that strategy using actual source changes (where possible), and c) far greater advocacy of the success of linux audio by its users and boot-CD makers .. ... would do the job. Good idea. Send me the money, and I'll pay people to do it ;-) . oh, and i guess it wouldn't hurt to have a macmusic.org-like linuxaudioapps.org clone around, too, though i know there are already a few sites perilously qualified for this slot .. I agree that we have a lot of pages but none of them is really helpful for a starter. We already had some discussion some time ago about that issue. Unfortunately, the guy who has initiated the idea left our community due to some differences. A central place would be fine, but this needs time and resources. Best regards ce
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-06-14 at 21:16 +0200, Jay Vaughan wrote: b) an [mplayer/skype] patch-fest to bring them in line with that strategy using actual source changes (where possible) Skype is closed source and the mplayer developers are a pain in the ass to deal with due to blatant pro-OSS (as in /dev/dsp) bias. If it were easy these would have been fixed long ago. Lee
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Tue, 2005-06-14 at 21:09 +0200, Jay Vaughan wrote: That's it? Why do people listen to this guy again, he seems to be just another idiot luser who blames ALSA for every XMMS bug. ever heard of netscape? jwz is one of the glory-children of that project, a very active F/OSS advocate over the years. this story is important because it is about advocacy, good and bad. Oh, that jwz. I guess he's not an idiot, but I still think his rant was idiotic. If he had posted on alsa-devel with some constructive criticism then it actually would have accomplished something. There are many examples of this in the past. Ranting on his blog just makes him look like an ass. Lee
