Re: [linux-audio-dev] [OT] Recommendations for high quality blank CDs
On 3/21/07, Jonathan Ryshpan [EMAIL PROTECTED] wrote: I need to make some CDs for archiving and need to buy some blanks of the highest quality, in the sense that data recorded on them will last the longest time. Does anyone have any suggestions? Useful web sites? I have thousands of burned CDs mostly 5 or 6 years old and the gold Kodaks have held up the best by far. Everything else develops pits and separates from the backing with age, and forget it if they ever get a drop of water on them. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/16/07, Jonathan Ryshpan [EMAIL PROTECTED] wrote: I've given up reading all the followups to this, which has (as you surely expected) ended in a religious discussion about GPL vs. BSD licenses. Yeah, it's really too bad that it's impossible to keep this discussion on a technical level without someone throwing out a religious argument. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Paul Davis [EMAIL PROTECTED] wrote: On Wed, 2007-03-14 at 08:56 -0400, Paul Coccoli wrote: Besides, what you want is probably impossible. You can't have pre-comiled, binary-only drivers *and* a custom kernel. in theory, you certainly can. but the kernel development team, and linus in particular, are not interested in an engineering effort/long term approach that makes this feasible. if you define a stable driver binary interface, you can change the kernel out around it and drivers keep working. linus has made it clear that he sees no reason to do this, and is perhaps even opposed to it for some possibly sound engineering arguments (though that is open to debate). Binary drivers make the kernel impossible to debug, and if the kernel devs created such a DBI, vendors would stop releasing open source drivers and pretty soon Linux would be no more stable than Windows. Why should Linux sacrifice stability just so vendors can keep their hardware interfaces secret? Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Gordon JC Pearce [EMAIL PROTECTED] wrote: On Wed, 2007-03-14 at 10:21 -0400, Lee Revell wrote: Binary drivers make the kernel impossible to debug, and if the kernel devs created such a DBI, vendors would stop releasing open source drivers and pretty soon Linux would be no more stable than Windows. Why should Linux sacrifice stability just so vendors can keep their hardware interfaces secret? This is exactly what I'm talking about. I *DON'T FUCKING CARE* what the manufacturers do or don't do with their hardware interfaces. What I *do* care about is having X break every couple of days because some kernel update. I have neither the time nor the inclination to try and work round other people's hangups. I think you misread my technical statement as a political one. I don't care about politics or the GPL, I just want Linux to be the most stable OS, and that can't happen if secret blobs of code are allowed to scribble all over kernel memory. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Christian Schoenebeck [EMAIL PROTECTED] wrote: Am Mittwoch, 14. März 2007 15:21 schrieb Lee Revell: Binary drivers make the kernel impossible to debug, That's an exaggerated statement. I would accept harder though. ;) With binary drivers kernel debugging requires the cooperation of the vendor in the best case, and lots of guesswork and reverse engineering in the worst case. The main technical argument in favor of open source is that anyone can fix a bug. With binary drivers, you're at the mercy of the vendor. At that point you might as well run Windows. Another technical argument for open source drivers is that vendors will put all kinds of garbage like AC3 encoding in the kernel if they're allowed to keep the code secret. Have you ever disassembled/decompiled a Windows driver? It's shocking what you find... and if the kernel devs created such a DBI, vendors would stop releasing open source drivers and pretty soon Linux would be no more stable than Windows. Why should Linux sacrifice stability just so vendors can keep their hardware interfaces secret? Not Linux' stability might suffer, but what you fear is that its reputation could do. Who says it's about reputation? I am talking about real world stability. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Paul Davis [EMAIL PROTECTED] wrote: On Wed, 2007-03-14 at 10:21 -0400, Lee Revell wrote: Why should Linux sacrifice stability just so vendors can keep their hardware interfaces secret? although i broadly agree with lee on most things, i think that this way of approaching this issue is unnecessarily confrontational. just flip it around ... why should vendors expose their hardware interfaces just to keep linux' reputation for stability up? i don't have a non-confrontational alternative, though :) I guess my response would be that the main reasons for the success of Linux are stability and performance which are direct results of the kernel source being open. Take that away and it's just a lame proprietary Unix that only the vendor can support. Whereas, secret interfaces are really tangential to the the quality of the hardware. My other response would be to point to all the successful vendors who *do* provide open Linux drivers. Creative released a GPL emu10k1 driver and went on to sell gazillions of those devices to Linux users, and the competition never cloned their hardware, because they patented their hardware innovations. Finally, hardware vendors are of course free to require a binary blob to use their gear, as long as it runs in userspace, like the newer Intel wireless and video stuff. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Gordon JC Pearce [EMAIL PROTECTED] wrote: On Wed, 2007-03-14 at 10:34 -0400, Lee Revell wrote: I think you misread my technical statement as a political one. I don't care about politics or the GPL, I just want Linux to be the most stable OS, and that can't happen if secret blobs of code are allowed to scribble all over kernel memory. Hm. In something like six years of using nVidia cards and their binary drivers, I have never had a problem that could be traced to the driver. Problems and lockups caused by the fan falling to bits are a different matter ;-) The plural of anecdotes is not data. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Christian Schoenebeck [EMAIL PROTECTED] wrote: It's not the kernel, but the binary driver that might introduce the instability. So in that case the user would have the option to use, or not to use that potential buggy binary driver. What if it's the driver for your SATA controller? Now you can't boot without it. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Fons Adriaensen [EMAIL PROTECTED] wrote: You should consider the position of a HW manufacturer who wants to develop a new product that may require a Linux driver for it. The project is planned, and a budget is set aside for driver development. If the kernel to driver interface can change at any moment, then it becomes almost impossible to estimate the economic value of the Linux driver - it could be useless the day after it's finished. I've been following kernel development closely for a few years now and I've never seen this happen. The interface does not change that fast. Even for vendors who work against ancient kernels and gratuitously ignore CodingStyle, it's usually trivial to get a driver in shape for inclusion. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Maarten de Boer [EMAIL PROTECTED] wrote: I think you misread my technical statement as a political one. I don't care about politics or the GPL, I just want Linux to be the most stable OS, and that can't happen if secret blobs of code are allowed to scribble all over kernel memory. I have an additional argument against binary drivers. Some years ago, we had a server with a Highpoint IDE RAID controller. We bought it because the Highpoint actually had an open source driver tgz for it on it on its webpage. It turned out though that this open source driver was a binary blob with some open source kernel glue code around it (just like the nvidia and ati drivers). Anyway, too late to go back, we used the controller with the binary driver, kernel 2.4. After a while had to to upgrade to a 2.6 kernel, but Highpoint only provided a 2.4 driver. This caused a lot of trouble. Heh, I forgot about that one - vendors who keep their source closed so they can lie about the capabilities of the hardware. I suspect they marketed a fakeraid (aka software RAID implemented at driver level) device as hardware RAID. This is common in sound drivers too - devices are advertised as supporting hardware AC3/DTS/whatever encoding while in fact the driver does it in software. Lee
Re: [linux-audio-dev] Getting out of the software game
On 3/14/07, Cornell III, Howard M [EMAIL PROTECTED] wrote: Actually, anecdotes is already plural. Dammit! /me hangs head in shame
[linux-audio-dev] Re: [linux-audio-user] Open letter to Steve Ballmer
On 3/2/07, Nick Copeland [EMAIL PROTECTED] wrote: If Microsoft patent any capabilities that are present in the ALSA codestream them ALSA itself is exempt from the patent. This is written into the patent laws, they cover the possibliity that somebody had a product that was later patented by some other, wiser party. If the company in potential infringment can prove prior implementation then they are exempt. Prior art doesn't exempt the first implementor, it invalidates the patent, at least in the US. Lee
Re: [linux-audio-dev] Re: [linux-audio-user] Open letter to Steve Ballmer
On 3/2/07, Lars Luthman [EMAIL PROTECTED] wrote: (regardless of whether the whole concept of patents is insane or not) You're referring only to software patents I hope? Lee
Re: [linux-audio-dev] List migration to linuxaudio.org : remaining issues.
On 3/1/07, Marc-Olivier Barre [EMAIL PROTECTED] wrote: (at least for dictionary based random spam if such a thing exists, and I have no doubt it does). I can verify that it certainly does exist. But the lists are subscribers only right? Lee
Re: [linux-audio-dev] microsoft mails
On 2/3/07, Leonard Ritter [EMAIL PROTECTED] wrote: On Sat, 2007-02-03 at 22:05 +0100, Lars Luthman wrote: Is there any actual programming going on at Microsoft, or are they all busy writing shady internal mails to each other? there have been numerous articles floating around from ex-ms employees complaining about the high level of bureaucracy --- how 12 people were involved in the shutdown menu feature, for example. so, yes, they are all busy writing shady internal mails, and telling fairy tales to customers. My first reaction was what kind of evil twisted individual would use Comic Sans MS as his email font? Lee
Re: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, Michael Ost [EMAIL PROTECTED] wrote: Now it is time for a leap to a newer OS --- 2.4 isn't giving us SATA drive support and our Wine is getting old (vinegar? %). Our code could do Windows pretty easily. Should I push for that, or move to a newer Linux? I would say it depends on how much Windows would cost per unit, and whether you can tolerate being at the mercy of vendors and Microsoft to fix any bugs you find. However I didn't realize that you were using 2.4. 2.6 with the -rt patches should definitely give better latency than Windows. In fact it's capable of uselessly low latencies like 0.66ms on some hardware, which is exactly the kind of thing the marketing guys love ;-) Lee
Re: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, David Olofson [EMAIL PROTECTED] wrote: There are a few hacks for RTAI and/or RTLinux, actually, but AFAIK, nothing for any serious hardware... (I did one myself a few years ago, for RTLinux and AudioPCI cards, IIRC.) There's no point these days - the 2.6 -rt kernel can already deliver latencies down to the hardware limit. Lee
Re: [linux-audio-dev] Old hat - comparison against windows
On 1/31/07, David Olofson [EMAIL PROTECTED] wrote: That said, as you can't use all CPU time on a UP machine anyway, and as cache issues seem to make multithreaded processing virtually pointless (with the possible exception of multicore CPUs), it's entirely possible that there is no real gain in cutting latencies below what 2.6-rt can provide. I don't know, but it might be worth some experiments... Maximum jitter with 2.6-rt is 20-50 microseconds last time I checked. So less than 5% even at a marginally useful period sizes like 32 frames. Lee
Re: [linux-audio-dev] block i/o scheduler for JACK
On Fri, 2007-01-05 at 23:52 +0300, Andrew Gaydenko wrote: (sorry for crossposting - have tried at LAU mailing list, but have not got any answer) Which kernel block i/o scheduler is most appropriate for JACK application? There are alternatives: Anticipatory I/O scheduler, Deadline I/O scheduler and CFQ I/O scheduler. I mean a kernel without RT-related patches. Should make no difference whatsoever for JACK clients - if they're written correctly, disk IO should not perturb them. CFQ is generally the best choice all around. Lee
Re: [linux-audio-dev] ALSA performance issues?
On Sat, 2006-12-23 at 14:08 +0100, Mario Lang wrote: Excuse my ignorance please, but how do I reliably determine if dmix is the default device? For instance, ogg123, which uses libao, only offers -o card:N and such, but no -o device:string, so I am kind of wondering if libao clients do perhaps always play on a hw device? libao's ALSA device selection is pretty much correct - it uses default PCM if no device is specified, and other devices can be selected like so: ogg123 -d alsa09 -o dev:hw:0,0 file.ogg Unfortunately the ALSA device selection syntax isn't documented in the manpage so I had to figure this out by code inspection and trial error... Lee
Re: [linux-audio-dev] Audio Driver Sample Code
On Sun, 2006-12-17 at 19:43 -0800, oscar si wrote: Hello: Could anyone please tell me if there are sample driver codes for PCI based sound card that are not using either alsa or oss? Why wouldn't you just write an ALSA driver? What are you trying to do? Lee
Re: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Tue, 2006-11-07 at 16:54 +, John Rigg wrote: On Tue, Nov 07, 2006 at 07:56:52AM -0700, Garett Shulman wrote: If you ask me... I would recommend that the alsa team drop all of the ambitions plugin stuff (except sampl rate bit rate) Without `ambitious plugin stuff' like pcm_multi, nobody would be able to use multiple sound cards with ALSA. The fact that pcm_multi has needed patching since January 2005 to make it work in duplex mode with jackd is only a minor inconvenience compared with not having it at all. Please, please keep pushing the ALSA guys to fix this. I keep raising the issue and every time the thread peters out with no resolution. Lee John
Re: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Thu, 2006-11-02 at 16:51 +0200, Hannu Savolainen wrote: Hi folks, The deprecated OSS issue needs some clarification. It's just the OSS/Free drivers that are still hanging around in the kernel. that are depracated. They are based on 10 years old version of the OSS architecture and lack all the improvements and features added during past years. Real linux drivers reside in the mainline kernel. Out of tree stuff is is irrelevant. Also, you've been promising for years that OSS will be free software again, I doubt anyone believes you at this point. Lee
Re: [linux-audio-dev] Re: [Jackit-devel] Multiplexing 4 channels on SPDIF
On Mon, 2006-10-30 at 13:40 +0200, Jussi Laako wrote: Fons Adriaensen wrote: Core Sound http://www.core-sound.com/default.php willsoon be offering a tetrahedral (Ambisonic) microphone at a very reasonable price. They are also working on a combined preamp + AD converter unit for this mic. This will be able to multiplex Sounds nice :) So here's my question to both the ALSA and JACK teams: what would be your idea of a solution for this ? Some ALSA plugin? Of course, doing it in JACK's ALSA backend is also reasonably simple, but would require small changes in many places to override samplerates, etc. I don't think it even needs to be a plugin, just tell ALSA about the audio format. Where can the detailed specs be downloaded? Lee
Re: [Jackit-devel] [linux-audio-dev] Re: Multiplexing 4 channels on SPDIF
On Mon, 2006-10-30 at 17:35 +0100, Alfons Adriaensen wrote: On Mon, Oct 30, 2006 at 10:07:06AM -0500, Lee Revell wrote: Some ALSA plugin? Of course, doing it in JACK's ALSA backend is also reasonably simple, but would require small changes in many places to override samplerates, etc. I don't think it even needs to be a plugin, just tell ALSA about the audio format. How can you tell ALSA that an SPDIF input is 4 channels ? The ALSA code would have to be extended... I'm not sure exactly where. I don't think it should be called SPDIF because SPDIF implies two channels. Where can the detailed specs be downloaded? According to the Core Sound website this thing is still in development, and the specs there are incomplete. What they want to do is trick hardware 2-ch recorders into accepting the 4-ch signal. So what is in reality 4 channels at 48 kHz will be presented as 2 channels at 96 kHz. I don't think it's useful to discuss further until technical details are available. When specs are available, this thread should probably be re-started on alsa-devel. Lee
Re: [Jackit-devel] [linux-audio-dev] Re: Multiplexing 4 channels on SPDIF
On Mon, 2006-10-30 at 18:52 +0100, Fons Adriaensen wrote: The real question is how to fit this into the existing architecture: - hardware presents itself as 2 * 96 kHz - user wants to see a device with 4 * 48 kHz. Is there any online documentation on how to write ALSA plugins ? No, ask on the ALSA list. Lee
Re: [linux-audio-dev] about MIDI timing...
On Wed, 2006-10-25 at 15:05 +, Chris Cannam wrote: Clemens: Most sound cards don't have an internal timer that could be used for MIDI timing. ALSA uses whatever timer is configured, the default for this is the RTC timer. It is? For ALSA sequencer queues? I thought the default was system timer. Maybe it just depends on the modules you have loaded. My impression from Rosegarden users' reports has been that trying to use the ALSA sequencer with the RTC timer (something I've never bothered with myself: I always use a 1000Hz system timer) is a reliable way to lock up your system completely, with most kernels from about 2.6.13 or so onwards. I've been meaning to investigate with the latest ALSA source and at least make a decent bug report for ages, but you know the way it is, there are only sixty hours in the day. It would be wonderful if some excellent person had fixed it in the meantime. This is/was a bug or multiple bugs in the kernel's RTC driver. It started to appear around 2.6.13 because that was the kernel release where they regressed the default timer granularity from 1ms to 2.5ms, forcing apps like Rosegarden to switch to RTC based timing. Should be fixed in the latest kernels. Lee
Re: [linux-audio-dev] about MIDI timing...
On Wed, 2006-10-25 at 16:42 +, Chris Cannam wrote: Me: No, it genuinely went from working to broken And actually, I think my recollection is wrong. I think it probably broke in 2.6.8-rt, and in mainline in either 2.6.9 or 2.6.10. Before that it worked fine, but we always used the system timer instead for RG because it seemed simpler (it was always 1000Hz then) and we stuck with that as the default and I guess rather abandoned the RTC option. Sorry for being so lax. If it does work now, then of course, that's great. You need to get the users having the problem to retest with kernel 2.6.18 or 2.6.19-rc*. Older kernels can't be fixed so what's the point? Lee
Re: [linux-audio-dev] best option for audiovisual synchrony
On Sun, 2006-10-22 at 15:00 +0200, Dominique Michel wrote: Le Sat, 21 Oct 2006 11:59:14 -0400, I think any Linux system with DRI can do this. Check /proc/interrupts - if your video card is listed, then you should have vsync interrupt capability. Lee I have a nvidia card in my box. If I use the nvidia driver, I get it in /proc/interrupts, but if I use the nv driver, the card don't use an IRQ. I am not a gamer, and for me, the nv driver is just better because I can use this IRQ for another hardware and get a better IRQ setup with my rt kernel and that already at the PIC level. If compatibility is a concern, I think at it will be better to use a mechanism provided by X that will exist on every single linux box, as to rely on a hardware mechanism that will not be found on every system. Interrupts are a hardware mechanism by definition. X cannot provide one if the hardware lacks this feature (or the driver fails to enable it) Lee
Re: [linux-audio-dev] best option for audiovisual synchrony
On Fri, 2006-10-20 at 16:53 -0400, Paul Davis wrote: On Fri, 2006-10-20 at 22:44 +0200, Tim Goetze wrote: [Fons Adriaensen] Input the vertical video sync signal via the audio card and analyse its timing in terms of audio samples (e.g. using a DLL). This will enable you to predict where the next sync will be in the audio input. Back in the 80s, the humble Commodore 64 could be readily programmed to fire an interrupt on vertical sync. Have 20 years of progress really deprived us of this fine feature, or is it just missing from X? it was missing from X until Xorg put it back in as an extension. its obviously not of much use in a general purpose X app, since the display may not be the host on which the app runs, making access to the vsync pulse pretty pointless. I think any Linux system with DRI can do this. Check /proc/interrupts - if your video card is listed, then you should have vsync interrupt capability. Lee
Re: [linux-audio-dev] recommend a card with the best SPDIF out
On Thu, 2006-09-21 at 20:36 +0400, Andrew Gaydenko wrote: Frank, Thanks! And which Audiophile do you mean? 2496 or 192? 2496, the AP192 is hardly supported at all due to lack of help from M-Audio. Andrew === On Thursday 21 September 2006 19:35, Frank Barknecht wrote: === Hallo, Andrew Gaydenko hat gesagt: // Andrew Gaydenko wrote: Lee, sorry, didn't understand 'function of the host OS and driver' (probably, my English isn't perfect :-)). As I understand a problem, for PCI case proper shielding, clean (on the card) power supply subcircuits and good generator are useful. For USB case - all these and syncing from *own* oscillator. Forget about USB, unless you're forced to e.g. on a laptop. For PCI cards, the M-Audio Delta cards are very good and not too expensive. If you only need stereo, then the M-Audio Delta Audiophile PCI is a very good and popular choice. Ciao
Re: [linux-audio-dev] recommend a card with the best SPDIF out
On Tue, 2006-09-19 at 19:33 +0400, Andrew Gaydenko wrote: - of course, without resampling, Which sample rates do you need to be able to play without software resampling? - (most important) minimal jitter. This should be a function of the host OS and driver, not the device right? Lee
Re: OT: Re: [linux-audio-dev] very nice looking HW -- somewhat off topic
On Thu, 2006-09-07 at 18:50 -0700, Stephen Cameron wrote: Another important question, are they willing to comply with the GPL? Many companies seem to believe it's legal to develop a closed source driver for Linux... Lee Is it not legal? Please check the archives of this list and linux-kernel, this has been discussed to death already. Lee
Re: [linux-audio-dev] plug:jack device channel-count
On Fri, 2006-08-25 at 00:30 +, carmen wrote: Yes, but what would be even more useful is to report this to the sweep developers. done. as it turns out, theres a divide-by-zero on alsahandle-num_channels or similar. ive noticed other ALSA apps will also fail with plug:jack (notably Twinkle) with an error very similar (eg, no available channels for opening), while others such as Ekiga or those using GStreamer, have no problems with plug:jack. are these apps working around it by trying to open channels even if the number available is reported to be 0? maybe this is a bug in jack:plug for not making up a number like at least 2, if alsa_pcm devices exist in jack.. I don't know - you failed to mention that you were using plug:jack. Probably no one ever tested this configuration. (I don't think plug:jack is well tested in general. The JACK API is simpler than ALSA so it's easier for apps to just support JACK.) You did mention that in your bug report I hope? Does Sweep really have no JACK support? Lee
Re: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure?
On Fri, 2006-08-18 at 12:38 -0400, Paul Davis wrote: On Fri, 2006-08-18 at 23:10 +0700, Mulyadi Santosa wrote: Is there any relationship between kernel HZ and audio timing? I imagine no. or almost none. recording audio doesn't involve using the system timer at all. the only clock involved is the sample clock that drives the audio interface. having HZ set too high could conceivably make the system more likely to xrun, but this is not likely with a fully RT kernel. High HZ will improve MIDI timing though. MIDI is more likely to be polled than interrupt driven. Lee
Re: [linux-audio-dev] Linux kernel HZ, audio latency and how to measure?
On Fri, 2006-08-18 at 20:26 -0400, Stephen Sinclair wrote: I've certainly seen setitimer()-driven sleeping get much better response time on a kernel compiled to 1000 Hz (with preemption) over one compiled to 100 Hz (without preemption). From this, I think it should be possible to say that one could read the audio card with smaller buffers more quickly, reducing latency. But I haven't made tests using audio, specifically, so I won't say more. I suspect the kernel driver and userspace API (ALSA or whatever) might need to be made to take advantage of it, but I know little about ALSA internals. Audio doesn't use setitimer()-driven sleeping. It's interrupt-driven, not timer-driven. Lee Steve On 8/18/06, Paul Davis [EMAIL PROTECTED] wrote: On Fri, 2006-08-18 at 23:10 +0700, Mulyadi Santosa wrote: Is there any relationship between kernel HZ and audio timing? I imagine no. or almost none. recording audio doesn't involve using the system timer at all. the only clock involved is the sample clock that drives the audio interface. having HZ set too high could conceivably make the system more likely to xrun, but this is not likely with a fully RT kernel.
Re: [linux-audio-dev] scaling jackinput to dbSPL
On Tue, 2006-08-15 at 16:51 +0100, Dan Mills wrote: This is dependent on the microphone, preamp and sound card in use, or for the output case, the soundcard, power amp gain and speaker sensitivity (plus room effects). You need to ensure that 120dbSPL at the transducer does not clip either hhe mic, preamp or soundcard and then find out what sample value this gives with your hardware. Calibrate that point as 120dbSPL, then as long as all your hardware is linear the rest of the thing will just work. FWIW, there is some work going on in ALSA to make the drivers use dB units for the mixer, rather than arbitrary scales. But of course this will only work for devices for which the developers have the full hardware specs. Lee
Re: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project
On Wed, 2006-07-26 at 17:29 -0500, Renich Bon Ćirić wrote: Thank you so much for the those words! ;=) As you saw at the links, the first goal is to get the source from Akai... even a beta. If that fails, we are gonna try and develop a whole OS. Why? That makes no sense. Why not just port Linux to it? Thanks again Marc-Olivier Barre wrote: On 7/26/06, Renich Bon Ćirić [EMAIL PROTECTED] wrote: Well, we are trying to make a proposal to Akai Pro so it releases the source code of the OS that runs on the MPC4000 Worstation/Sampler. If you want to join and help, go to http://www.woralelandia.com/openmpc/ # Reference http://www.mpc-forums.com/viewtopic.php?t=54825 I took a look at the specs Akai sent you. If you intend to port linux to it, you have a nice begining there. You have the full list of hardware pieces inside, and all the schematics. Even if akai don't give you their OS source, everything is still possible.
Re: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project
On Wed, 2006-07-26 at 18:00 -0500, Renich Bon Ćirić wrote: Well, very wise words you say. But, on the other hand, this piece of hardware is worth 3,000 usd. We have a ton of users to think about. We must provide compatibility with it's native format. It would be cool to be able to use all the OpenSource arsenal out there. But first, we need to clone... at least, that's what they have said (the users) Just port Linux to it then develop the support for the native file systems/formats/etc. MUCH less work than writing your own OS. (BTW top posting is considered bad form on this list) It sounds like you're responding to user requests of some kind - do you have a link? What exactly are you trying to accomplish? Lee
Re: [linux-audio-dev] Basic MIDI question
On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote: (ALSA's sequencer event - rawmidi converter uses running status by default.) By default - so it can it be disabled? How? Lee
Re: [linux-audio-dev] Basic MIDI question
On Tue, 2006-07-25 at 18:11 +0200, Clemens Ladisch wrote: Lee Revell wrote: On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote: (ALSA's sequencer event - rawmidi converter uses running status by default.) By default - so it can it be disabled? How? snd_midi_event_no_status(), but this cannot be changed by a driver. This setting wouldn't apply to data written directly to the rawmidi port anyway. It would in fact be useful for my testing to add a command line option to aplaymidi to have it not use running status. But, I see that aplaymidi rolls its own events rather than using snd_midi_event_t, so it's not at all clear how to do it. Lee
Re: [linux-audio-dev] Open MPC OS Initiative
Plain text mail is preferred over HTML on this list. On Tue, 2006-07-25 at 14:18 -0500, Renich Bon Ćirić wrote: If anyone would like to join the OpenMPC OS dev team, welcome. http://www.woralelandia.com/openmpc/blog/ Are you attempting to port Linux to it, or develop a new OS from the ground up? Lee
[linux-audio-dev] Basic MIDI question
I've never been a MIDI expert but I'm now having to learn. I have a
question about this excerpt of a MIDI file viewed with hexedit.
1BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F .=51.:9..71..1.
1BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0[..y.p.9s..
1BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80 6iK.6C0D..
1BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E 9B...7c..C{.p.^
1BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E 11 ..:f..70..C21.
Take the sequence 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F in
the first line for example. I know that 0x80 is note-off, and 0x3D are
note number and 0x35 the velocity of the note-off. But what the heck is
the next byte, 0x31? The MIDI standard says note-off is one status byte
followed by 2 data bytes!
Lee
Re: [linux-audio-dev] Basic MIDI question
On Mon, 2006-07-24 at 22:57 +0200, Lars Luthman wrote:
On Mon, 2006-07-24 at 16:38 -0400, Lee Revell wrote:
I've never been a MIDI expert but I'm now having to learn. I have a
question about this excerpt of a MIDI file viewed with hexedit.
1BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F
.=51.:9..71..1.
1BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90
...0[..y.p.9s..
1BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80
6iK.6C0D..
1BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E
9B...7c..C{.p.^
1BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E 11
..:f..70..C21.
Take the sequence 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F in
the first line for example. I know that 0x80 is note-off, and 0x3D are
note number and 0x35 the velocity of the note-off. But what the heck is
the next byte, 0x31? The MIDI standard says note-off is one status byte
followed by 2 data bytes!
That's the standard for MIDI that is sent realtime over a wire. When it
is stored in a file you also need some sort of timestamp for each event.
The extra byte is the number of clock ticks to wait before you play the
event (since the last event).
OK. I was confused because I also see these timestamps when snooping
the MIDI output stream inside the kernel's MPU401 driver. I guess I
assumed that aplaymidi would deliver the events with correct timing,
rather than passing the timestamps through.
I guess if I played back the same MIDI file with a full featured
sequencer, I would only see the actual MIDI events in the driver?
Also, why doesn't every event have a timestamp? For example 81 0C 90
30 5B 00 90 3C 79 81 70? I guess multiple events can be scheduled in
one tick?
Lee
Re: [linux-audio-dev] Basic MIDI question
On Tue, 2006-07-25 at 01:43 +0200, Nicolas Pouillon wrote: [Mon, 24 Jul 2006 17:09:02 -0400] Lee Revell [EMAIL PROTECTED] eut le bonheur d'_crire: Also, why doesn't every event have a timestamp? For example 81 0C 90 30 5B 00 90 3C 79 81 70? I guess multiple events can be scheduled in one tick? Actually delta times between events are encoded with a variable length value. As long as bit 7 is 1, you must drop this very bit and add next byte in the value decoding. Here; 81 0c is a variable length value: delta 81 0cwhich is ((0x7f 0x81) 7) | 0x0c = 0x8c event 90 30 5b delta 00 event 90 3c 78 delta 81 70which is 0xf0 hth Ugh. All I need to do is snoop note on, note off, and the note number. But you're saying that 0x81 is sometimes part of a timestamp, and other times it means note off on channel 1? So you are saying my driver needs to have full knowledge of the MIDI state machine in order to snoop note on and note off? Lee
Re: [linux-audio-dev] Basic MIDI question
On Tue, 2006-07-25 at 01:19 +0200, Jens M Andreasen wrote: On Mon, 2006-07-24 at 17:55 -0400, Lee Revell wrote: Ugh. All I need to do is snoop note on, note off, and the note number. But you're saying that 0x81 is sometimes part of a timestamp, and other times it means note off on channel 1? So you are saying my driver needs to have full knowledge of the MIDI state machine in order to snoop note on and note off? Driver? This is a driver for a midi-port on a sound-card or a some kind of midi-file player? It's similar to a driver for a MIDI port on a sound card, except the driver additionally has to respond to note on and note off by twiddling some other bits in the hardware. It's equivalent to having to flash an LED for note on and another for note off. I wrote the driver as an ALSA rawmidi device, which was probably not the best idea - I did not realize at the time that I would have to interpret the MIDI stream. An ALSA kernel sequencer client would have been more appropriate. I think I can get away with always treating 0x90 as note on and 0x80 as note off regardless of the context. (I can't release source or give the hardware details now, as the hardware is still being developed) Lee
Re: [linux-audio-dev] Basic MIDI question
On Tue, 2006-07-25 at 01:33 +0200, Jens M Andreasen wrote: On Mon, 2006-07-24 at 19:28 -0400, Lee Revell wrote: On Tue, 2006-07-25 at 01:19 +0200, Jens M Andreasen wrote: On Mon, 2006-07-24 at 17:55 -0400, Lee Revell wrote: Ugh. All I need to do is snoop note on, note off, and the note number. But you're saying that 0x81 is sometimes part of a timestamp, and other times it means note off on channel 1? So you are saying my driver needs to have full knowledge of the MIDI state machine in order to snoop note on and note off? Driver? This is a driver for a midi-port on a sound-card or a some kind of midi-file player? It's similar to a driver for a MIDI port on a sound card, except the driver additionally has to respond to note on and note off by twiddling some other bits in the hardware. It's equivalent to having to flash an LED for note on and another for note off. I wrote the driver as an ALSA rawmidi device, which was probably not the best idea - I did not realize at the time that I would have to interpret the MIDI stream. An ALSA kernel sequencer client would have been more appropriate. Confused again here. There are no delta-times in the midi-stream. You mean: ... have to interpret the midi *file* I think it's me that's confused - as you can see I'm certainly not a MIDI expert. When playing a MIDI file to a rawmidi port with aplaymidi, it was not clear to me that it just passes the file through - I was under the impression that the driver would only see the actual events, not the timestamps and other metadata. Lee
Re: [linux-audio-dev] Basic MIDI question
On Tue, 2006-07-25 at 01:47 +0200, Jens M Andreasen wrote: On Mon, 2006-07-24 at 19:38 -0400, Lee Revell wrote: I think it's me that's confused - as you can see I'm certainly not a MIDI expert. When playing a MIDI file to a rawmidi port ... $man aplaymidi -p, --port=client:port,... Sets the sequencer port(s) to which the events in the MIDI file(s) are sent. - I think it is unpossible to make it use rawmidi. ALSA takes care of the sequencer port-rawmidi device translation. Says sequencer (which will do the timing.) Can you jack in after the sequencer has performed its magic, and you have the actual midi-stream? I thought I was doing exactly what you suggect, by looking at the data in the driver right before it goes to the hardware. I'll just use a real sequencer for testing rather than aplaymidi. Lee
Re: [linux-audio-dev] FYI: GUADEC 2006 Sound BOF
On Mon, 2006-07-17 at 12:00 +0200, Jan Weil wrote: Apparently, a Sound BOF took place at GUADEC 2006 http://guadec.org/GUADEC2006. Slides that were presented: http://etudiant.epita.fr/~lureau_m/GUADEC06-Audio-BOF/ It seems that PulseAudio http://pulseaudio.org/, formerly known as Polypaudio, could be (is?) GNOME's new audio server of choice replacing esd. Great. One of the bullet points on the Future directions slide is Professional audio?. So it was not designed for professional use from the ground up. If Apple can design a single sound system that's usable for desktop toys AND pro audio why can't we? Lee
Re: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write
On Wed, 2006-07-12 at 23:43 +0200, jaromil wrote: my solution so far is assuming that boolean is atomical. all multi threaded handling i wrote is based on this assumption: i use it in pipe and linklist classes, but semaphores could also be there. i found no probems and good speed so far ... and life is boring without risks :)) How does that help with IPC? I thought this thread was about a realtime safe IPC mechanism? Lee
Re: [linux-audio-dev] Re: LinuxSampler license
On Sat, 2006-07-08 at 19:02 +0300, Juhana Sadeharju wrote: In gimp list, I mentioned that I don't want my software to be used in Windows. That would encourage people to install Linux. My plan was to use GPL + Windows exclusion. I was very clearly informed that it would not work. Then why similar works for Linuxsampler? It doesn't work. That's the whole point of this thread. Lee
Re: [linux-audio-dev] fst, VST 2.0, kontakt
On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: As defined by the FSF, no, it is not free software. If you use the freebeerian definition, you don't have to pay its authors to use it, yes, it is. In the Linux world free software means free as in speech. No one uses free software to refer to closed source software that's given away for free. Lee
[linux-audio-dev] Re: [linux-audio-user] [ANN] Aqualung 0.9beta5 released
On Fri, 2006-06-30 at 11:53 +0200, Tom Szilagyi wrote: Aqualung: Music Player for GNU/Linux http://aqualung.sf.net Release 0.9beta5 It is our greatest pleasure to announce the fifth official beta release of Aqualung. Some features you'd rarely stumble upon in other players (at least not too many of them at once): * Gapless playback (designed for this from the ground up) * High quality decoders (eg. libMAD for mp3), many supported formats * High-quality sample rate conversion support via libsamplerate * LADSPA support * Music Store for organizing your music * And much, much more... We hope you will enjoy this release. The release ChangeLog follows below. Do you guys have any interest in getting this into Debian/Ubuntu? The only .debs I could find are old (for Sarge?) Lee
Re: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels
On Mon, 2006-06-26 at 22:35 +0200, Pieter Palmers wrote: Another strange thing is: why doesn't the tasklet finish, so that it can be 'unscheduled'? I have my IRQ priorities higher than any other RT threads, so I would expect that the tasklet can finish. Or is tasklet_kill not-preemtible? that would be very strange as I would expect that busy waiting on something in a non-preemptible code path on a single-cpu system always deadlocks. When are you going to report this to Ingo + LKML + the other -rt developers? Lee
Re: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels
On Tue, 2006-06-27 at 21:20 +0200, Pieter Palmers wrote: Lee Revell wrote: On Mon, 2006-06-26 at 22:35 +0200, Pieter Palmers wrote: Another strange thing is: why doesn't the tasklet finish, so that it can be 'unscheduled'? I have my IRQ priorities higher than any other RT threads, so I would expect that the tasklet can finish. Or is tasklet_kill not-preemtible? that would be very strange as I would expect that busy waiting on something in a non-preemptible code path on a single-cpu system always deadlocks. When are you going to report this to Ingo + LKML + the other -rt developers? After I do the printk testing to pinpoint the problem a little more precise (as you suggested yesterday). However, I didn't feel like iterating through the recompile kernel/crash/reboot cycle even more yesterday. Is there any underlying reason for this question? Only that you seem to have found a bug in -rt and I'd like to get it fixed. Lee
Re: [linux-audio-dev] ieee1394 deadlock on RT kernels
On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: Ben Collins wrote: On Mon, 2006-06-26 at 10:11 +0200, Pieter Palmers wrote: Lee Revell wrote: Can we please use Reply to All for all followups, as is the convention in kernel development? It's annoying to follow a thread when some of it is in my Inbox, some is on LAD, and some apparently was mailed privately ;-) Lee
Re: [linux-audio-dev] ieee1394 deadlock on RT kernels
On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: Of course. My monday-morning bad temper is over by now, and I hope I didn't transfer it to any of you. I'll provide the panic, one way or another. Can you reproduce the problem on a non-RT kernel? Lee
Re: [linux-audio-dev] ieee1394 deadlock on RT kernels
On Mon, 2006-06-26 at 21:05 +0200, Pieter Palmers wrote: Lee Revell wrote: On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: Of course. My monday-morning bad temper is over by now, and I hope I didn't transfer it to any of you. I'll provide the panic, one way or another. Can you reproduce the problem on a non-RT kernel? No, it only occurs with RT kernels, and only with those configured for PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with threaded IRQ's etc... only switched over the preemption level in the kernel config). I've uploaded the photo's of the panic here: http://freebob.sourceforge.net/old/img_3378.jpg (without flash) http://freebob.sourceforge.net/old/img_3377.jpg (with flash) both are of suboptimal quality unfortunately, but all info is readable on one or the other. Can you add debug printk's before and after tasklet_kill() in ohci1394_unregister_iso_tasklet to see where it locks up? Lee
Re: [linux-audio-dev] ieee1394 deadlock on RT kernels
On Mon, 2006-06-26 at 21:44 +0200, Pieter Palmers wrote:
Lee Revell wrote:
On Mon, 2006-06-26 at 21:05 +0200, Pieter Palmers wrote:
Lee Revell wrote:
On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote:
Of course. My monday-morning bad temper is over by now, and I hope I
didn't transfer it to any of you. I'll provide the panic, one way or
another.
Can you reproduce the problem on a non-RT kernel?
No, it only occurs with RT kernels, and only with those configured for
PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with
threaded IRQ's etc... only switched over the preemption level in the
kernel config).
I've uploaded the photo's of the panic here:
http://freebob.sourceforge.net/old/img_3378.jpg (without flash)
http://freebob.sourceforge.net/old/img_3377.jpg (with flash)
both are of suboptimal quality unfortunately, but all info is readable
on one or the other.
Can you add debug printk's before and after tasklet_kill() in
ohci1394_unregister_iso_tasklet to see where it locks up?
That's the first thing I did: the printk before tasklet_kill succeeds,
the one right after the tasklet_kill doesn't.
OK that's what I suspected.
It seems that the -rt patch changes tasklet_kill:
Unpatched 2.6.17:
void tasklet_kill(struct tasklet_struct *t)
{
if (in_interrupt())
printk(Attempt to kill tasklet from interrupt\n);
while (test_and_set_bit(TASKLET_STATE_SCHED, t-state)) {
do
yield();
while (test_bit(TASKLET_STATE_SCHED, t-state));
}
tasklet_unlock_wait(t);
clear_bit(TASKLET_STATE_SCHED, t-state);
}
2.6.17-rt:
void tasklet_kill(struct tasklet_struct *t)
{
if (in_interrupt())
printk(Attempt to kill tasklet from interrupt\n);
while (test_and_set_bit(TASKLET_STATE_SCHED, t-state)) {
do
msleep(1);
while (test_bit(TASKLET_STATE_SCHED, t-state));
}
tasklet_unlock_wait(t);
clear_bit(TASKLET_STATE_SCHED, t-state);
}
You should ask Ingo the other -rt developers what the intent of this
change was. Obviously it loops forever waiting for the state bit to
change.
Lee
Re: [linux-audio-dev] ieee1394 deadlock on RT kernels
On Mon, 2006-06-26 at 21:44 +0200, Pieter Palmers wrote:
Lee Revell wrote:
On Mon, 2006-06-26 at 21:05 +0200, Pieter Palmers wrote:
Lee Revell wrote:
On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote:
Of course. My monday-morning bad temper is over by now, and I hope I
didn't transfer it to any of you. I'll provide the panic, one way or
another.
Can you reproduce the problem on a non-RT kernel?
No, it only occurs with RT kernels, and only with those configured for
PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with
threaded IRQ's etc... only switched over the preemption level in the
kernel config).
I've uploaded the photo's of the panic here:
http://freebob.sourceforge.net/old/img_3378.jpg (without flash)
http://freebob.sourceforge.net/old/img_3377.jpg (with flash)
both are of suboptimal quality unfortunately, but all info is readable
on one or the other.
Can you add debug printk's before and after tasklet_kill() in
ohci1394_unregister_iso_tasklet to see where it locks up?
That's the first thing I did: the printk before tasklet_kill succeeds,
the one right after the tasklet_kill doesn't.
Actually the problem might not be the change to tasklet_kill() but the
change to tasklet_unlock_wait().
include/linux/interrupt.h:
#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT)
static inline void tasklet_unlock_wait(struct tasklet_struct *t)
{
while (test_bit(TASKLET_STATE_RUN, (t)-state)) { barrier(); }
}
#else
# define tasklet_unlock_wait(t) do { } while (0)
Can you add a printk before that while loop?
Lee
Re: [Jackit-devel] [linux-audio-dev] What valgrind says
On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard wrote: On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro Lopo wrote: Paul Davis wrote: they don't matter. they are the result of writing a byte to a FIFO to wake up an(other) client. the contents of the byte do not make any difference at any point. Regardless of whether this is a bug or not it would be really nice if this could be fixed. Fixing it means that other people valgrinding their apps which use the Jack libs don't see warnings about Jack. ++ The last thing we need is MORE valgrind warnings.. I have not looked closely at the code, but could it be considered an information leak if you're using a byte of unitialized data? Lee
Re: [linux-audio-dev] ieee1394 deadlock on RT kernels
On Mon, 2006-06-26 at 01:08 +0200, Pieter Palmers wrote: Hi, We are experiencing 'soft' deadlocks when running our code (Freebob, i.e. userspace lib for firewire audio) on RT kernels. After a few seconds, I get a kernel panic message that signals a soft lockup. Can we see the kernel panic message? ;-) Lee The problems occur when an ISO stream (receive and/or transmit) is shut down in a SCHED_FIFO thread. More precisely when running the freebob jackd backend in real-time mode. And even more precise: they only seem to occur when jackd is shut down. There are no problems when jackd is run without RT scheduling. I havent been able to reproduce this with other test programs that are shutting down streams in a SCHED_FIFO thread. printk() debugging point to the tasklet_kill() call in ohci1349_unregister_iso_tasklet (drivers/ieee1394/ohci1394.c), that doesn't seem to return. For experiment, i've put a tasklet_disable before the tasklet_kill, and that causes the soft lockup to be due to the tasklet_disable. I would like to ask if anyone has a clue why this is happening. The only thing I can come up with is that jackd is stopped by a CTRL-C, and that the stream shutdown happens in signal handler context, which somehow interacts with the tasklet_kill. But I don't have the time now to dig into this, so for a change I ask for advice early instead of first banging my head against the wall for some days :). Thx, Pieter Palmers
Re: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency
On Fri, 2006-06-23 at 12:12 +0200, Pieter Palmers wrote: Lee Revell wrote: On Fri, 2006-06-23 at 09:44 +0930, Jonathan Woithe wrote: Despite what the log says, this was running a 2.0 GHz Dothan Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both the stress tester and the monitor were run with RT privilege access. The firewire interface used has a TI OHCI chipset. I apologise that the run was particularly short and that therefore the statistics aren't particularly good, but it does seem to confirm the observations you made on your machine. The large latencies only occur when the stress tester is running. What if you run the latency tester at RT priority 99? Testing at 80 is not particularly useful. Why not? If the 1394 test user thread has a lower priority, and the ohci1394 irq priority is also lower, there is no reason for the latency tester to be preempted by them. Because as you stated below the system timer runs at a higher priority by default. I wanted to rule out preemption by the system timer thread. If anything else is running at 99, what happens if you lower those other processes to 98? I'll have to recheck, but if I remember correcly I have done this experiment. The only thing at 99 is the system timer. I tried giving it a lower priority than the latency test thread, which didn't change anything. OK thanks, that answers my question. Pieter
Re: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency
On Fri, 2006-06-23 at 09:44 +0930, Jonathan Woithe wrote: Despite what the log says, this was running a 2.0 GHz Dothan Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both the stress tester and the monitor were run with RT privilege access. The firewire interface used has a TI OHCI chipset. I apologise that the run was particularly short and that therefore the statistics aren't particularly good, but it does seem to confirm the observations you made on your machine. The large latencies only occur when the stress tester is running. What if you run the latency tester at RT priority 99? Testing at 80 is not particularly useful. If anything else is running at 99, what happens if you lower those other processes to 98? What processes do you have running at RT priority 80 or above? Does the Firewire stack do a lot of its work in timers? Lee
Re: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the
On Fri, 2006-06-23 at 10:19 +0930, Jonathan Woithe wrote: At the time I ran the tests there were no other usermode processes running at any RT priority. Only the latency analyser itself and the ieee stress tester had elevated RT priorities. Also the system hasn't had priorities of kernel things tuned on startup - the system is a bog-standard 2.6.16-rt25 running as booted. In the -rt kernel IRQ handlers run as user processes with realtime priority. You have to use ps to check. Lee
[linux-audio-dev] Re: [Jackit-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency
On Wed, 2006-06-21 at 00:21 +0200, Pieter Palmers wrote: Hi all, This weekend I've discovered a (serious) kernel scheduling latency issue with the current ieee1394 kernel drivers. Before I submit something about this to lkml, I'd like some more tests. I've been able to reproduce this on two different machines, so I suspect that this is a more general problem. The problem summary is that running ieee1394 ISO traffic can cause scheduling latency spikes up to 1ms, even for RT threads with higher priority. Latency tracer output please? Use 2.6.16 with this patch: http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.16.patch Lee
Re: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write
On Mon, 2006-06-19 at 23:11 +0200, Stefan Westerfeld wrote: The spin_lock(bh-lock) is the one I was referring to in my earlier mail. Taking a spinlock should be realtime safe - they are not supposed to be held for long and cannot sleep. Worst case scenario should be that you spin for a few hundred microseconds. It's a bug if a spinlock is held for much longer or is heavily contended. Lee
Re: [linux-audio-dev] Writing LADSPA plugins in high level language?
On Wed, 2006-06-14 at 07:47 +0200, Alex Polite wrote: Hi there. Is it possible to write LADSPA plugins in anything but C/C++? I prefer perl, ruby or python. How do you do realtime in an interpreted language? How can you guarantee the interpreter won't do something that's not RT safe during a critical section? Lee
Re: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write
On Thu, 2006-06-08 at 23:25 +0300, Jussi Laako wrote: Lee Revell wrote: But, from the original post it seems that pthread_cond_signal is not realtime safe as it locks a mutex: Just about any syscall nowadays potentially acquires some sort of lock inside kernel. The code in question was fron glibc, not the kernel. Lee
Re: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write
On Wed, 2006-06-07 at 20:32 +0200, Fons Adriaensen wrote:
On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis wrote:
nice to hear that they are faster. on the other hand, once again POSIX
screws us all over by not integrating everything into a single blocking
wait call. i've said it before, i'll say it again - this is one of the
few things that the win32 API gets right - you can block in one call on
almost *anything*. AFAICT, you cannot select/poll on a msg queue.
You can build such a thing on top of condition variables - that
is what they exists for - to let a thread wait one any condition
you may want, no matter how complicated.
But, from the original post it seems that pthread_cond_signal is not
realtime safe as it locks a mutex:
__pthread_cond_signal (cond)
pthread_cond_t *cond;
{
/* Make sure we are alone. */
lll_mutex_lock (cond-__data.__lock);
/* Are there any waiters to be woken? */
if (cond-__data.__total_seq cond-__data.__wakeup_seq)
{
/* Yes. Mark one of them as woken. */
++cond-__data.__wakeup_seq;
++cond-__data.__futex;
/* Wake one. */
lll_futex_wake (cond-__data.__futex, 1);
}
/* We are done. */
lll_mutex_unlock (cond-__data.__lock);
return 0;
}
How can glibc guarantee that we are not put to sleep if there is
contention?
Lee
Re: [linux-audio-dev] real time priority programming tutorial
On Fri, 2006-06-02 at 09:32 +0100, [EMAIL PROTECTED] wrote: On Fri, 02 Jun, 2006 at 01:06AM +0200, Jens M Andreasen spake thus: On Thu, 2006-06-01 at 10:06 -0700, Alex wrote: Does anyone have a link to a reference about making apps with real time priority capabilities? As such there is no difference between an RT app and a not RT app, except that the former varity might not work as advocated I think he meant: how you demand RT priority and what you should do not to screw it up once you have it. man sched_setscheduler I figure I can just look at jack but it would be nice see some tutorial, to learn what is actually happening/necessary, trade-offs, etc. thanks, Alex Norman
Re: [linux-audio-dev] real time priority programming tutorial
On Thu, 2006-06-01 at 10:06 -0700, Alex wrote: Does anyone have a link to a reference about making apps with real time priority capabilities? I figure I can just look at jack but it would be nice see some tutorial, to learn what is actually happening/necessary, trade-offs, etc. The question is almost impossibly vague. It is a big area. Can you be more specific? What are you trying to do? Lee
Re: [linux-audio-dev] compiler problem?
On Fri, 2006-05-26 at 05:05 -0500, Gene Heskett wrote: Greetings; Since I can't get any of the common VoIP things to work due to a lack of duplex function in my lappy's chipset, and my inability to convince the person bugtrack assigned to my bugzilla entry that its not my fault, I thought I'd try zfone next. Um, you never answered tiwai's last question. Grr, you make the things too complex. Let's sort out the thing straight. The duplex problem and the inproper recording are different things. First, check whether both non-duplex playback and recording work properly. For checking playback, you can use speaker-test program in alsa-utils package, too. Run speaker-test -c2 -tw, for example. As I mentioned, you can test recording of the played stream by setting Capture Source to Mix. It needs no extra hardware setup, so no hard work after running a full marathon. If the full-duplex works by this way, skype and other programs should work as well -- as long as you set up the mixer correctly. Anyway, don't use audacity or whatever apps might be using OSS emulation for tests. They can't be used as references. Use basic tools included in ALSA packages for primary tests. We have to debug one thing at a time, and using the simplest possible tools, rather than some huge VOIP app that goes through the OSS layer. If you are not interested in debugging it further I will close the report. Lee
Re: [linux-audio-dev] crossplatform atomics
On Thu, 2006-05-25 at 19:57 +0300, Kai Vehmanen wrote: Does someone have a good reference on this? I think the writes just are not atomic, but you can use some tricks [1] to implement atomic behaviour by spinning until the operation succeeds. Do we still care about 32 bit sparc? Lee
Re: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs.
On Sat, 2006-05-20 at 11:07 -0500, Gene Heskett wrote: Or chipset problems. Occasionally, skype will run for a few minutes before things start pulling the flush handle, almost as if its heat related. Having the hammer of being a CET, one tends to think of hardware as the nail. Are there newer alsa things to try? This is a fully uptodate FC5 install, i386 on an amd turion 64. You could try ALSA 1.0.11, but I don't think this driver has changed. I would report the bug to the alsa-user list. Lee
Re: [linux-audio-dev] ATI-IXP overdrives PCM
On Sat, 2006-05-20 at 17:07 +, c wrote: On Sat May 20, 2006 at 09:27:56AM -0500, Gene Heskett wrote: often sounding as if the playback is of a file that over-drove the d/a in playback, or the a/d in the recording, eg clipped. ... the ATI-IXP audio stuffs loaded the ATIIXP in my MSI exhibits this same issue. essentially, if the 'PCM' level is set to 100%, things are horribly overdriven. the solution is to set the Master to 100%, and adjust volume with PCM, instead of vice versa. i guess whether this is a hardware bug or a driver bug depends on if PCM is the last point of software contact with the stream and master trims the levels after that, or if PCM just does some multiplication on the bits before passing them to the Master.. Distortion if all volumes are set to 100% is not necessarily a bug. It's just the way some hardware works. Lee
Re: [linux-audio-dev] ATI-IXP overdrives PCM
On Sat, 2006-05-20 at 17:10 +, c wrote: not sure how to cap the volume at 80% with aoss, though. wasnt around in the OSS days..and prefer my apps don't relive them ;) Just don't turn up the PCM control past 80%. Lee
Re: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs.
On Thu, 2006-05-18 at 22:19 -0500, Gene Heskett wrote: Any hints that result in getting something like skype or ekiga working will be applied with many profuse thanks offered. What ALSA version (/proc/asound/version)? Which driver is being used? Any change if you run the apps with aoss? e.g. aoss ./skype Lee
[linux-audio-dev] Re: [linux-audio-user] more questions on FST
On Wed, 2006-05-17 at 13:35 -0500, Aaron Krister Johnson wrote: Another question--barring that, if I do replace glibc, will I have to recompile my kernel, wine, etc? You would have to recompile EVERYTHING. Replacing glibc is major surgery. It's best to just upgrade to a newer distro. Lee
Re: [linux-audio-dev] Re: [linux-audio-user] more questions on FST
On Wed, 2006-05-17 at 21:43 +0200, [EMAIL PROTECTED] wrote: On Wed, May 17, 2006 at 03:40:44PM -0400, Lee Revell wrote: On Wed, 2006-05-17 at 13:35 -0500, Aaron Krister Johnson wrote: Another question--barring that, if I do replace glibc, will I have to recompile my kernel, wine, etc? You would have to recompile EVERYTHING. Replacing glibc is major surgery. thats not true lee. i switched glibcs around when debugging fst. just make sure you have the old version around, and a boot cd so that you can recover from failure. also make sure you enable tls. and have a 2.6.x kernel... I guess it depends on the distro. There was a recent report of someone trying to upgrade glibc and they ended up having to reinstall. I would think with a source based distro you'd have to recompile quite a bit, but I haven't used one myself. Does FST definitely require NPTL? Lee
Re: [linux-audio-dev] 3D fft analysis program
On Mon, 2006-05-15 at 19:02 +0200, Uwe Koloska wrote: Am Montag, 15. Mai 2006 20:31 schrieb Esben Stien: Uwe Koloska [EMAIL PROTECTED] writes: The website doesn't say so ... Yes, it does. If you navigate to the download section and then follow the source link. Ok, but I think GPL and purchase is a contradiction, isn't it? No, it's perfectly legal to sell GPL software. Here's the contradiction: License Agreement: * This software is free and it comes with no warranty. * We are not liable for any damage caused by the use of this product. * You are not allowed to distribute this software. * You are not allowed to reverse engineer this software. * By downloading the baudline .tar package you agree to the terms of our license agreement. * If you desire a warranty on this product and you wish to purchase a support contract then please contact us. GPL does not allow additional restrictions. Lee
Re: [linux-audio-dev] 3D fft analysis program
On Mon, 2006-05-15 at 19:29 +0200, Uwe Koloska wrote: Am Montag, 15. Mai 2006 19:15 schrieb Lee Revell: Ok, but I think GPL and purchase is a contradiction, isn't it? I have had better said: GPL and purchasing the source is a contradiction, isn't it? No, it's perfectly legal to sell GPL software. Yes, but not the sourcecode. You can charge for handling and don't have to provide a direct download, but you are not allowed to purchase the code. And if the code is public anyone can give it away for free. So, if they really have chosen to make the code available under the terms of the GPL (and noone has forced them to do) they must follow the license and can't make additional restrictions as you have stated. Actually, you can sell the sourcecode, but it doesn't make sense to because you also have to provide it for free. Uwe
Re: [linux-audio-dev] LADSPA 2 name
On Fri, 2006-05-12 at 12:04 +0100, peter wrote: On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional hmm ZAP. not only the least offensive recursive acronym i've seen but it's Why was 'peep' offensive? urbandictionary was of no help. also catchy, has one syllable and sounds like the ZAPP. What's ZAPP? infact, i reckon it has more bounce to the ounce. LV2 has non of the above but is also a good enough choice to my mind. =) pete.
Re: [linux-audio-dev] LADSPA 2 name
On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional
Re: [linux-audio-dev] n00b friendly latency tester
On Sun, 2006-05-07 at 16:16 +0100, Martin Habets wrote: On Sat, May 06, 2006 at 10:13:42AM -0400, Lee Revell wrote: Same as the existing CLI tools - it would start an RT thread that polls on the RTC, then tell the user to generate some load (switch windows, do a find /, pingflood the default gateway, whatever), then report back the maximum latency. In stead of telling the user to generate some (unpredictable) load I would suggest re-using the parts from the alsa latency tester tool that automatically spawn another process with a known load. Yeah I was thinking about this. There are workloads that cause xruns (like display activity with some video drivers) that are hard to simulate this way. Maybe we could generate some load and tell the user to generate their own load at the same time. Lee
Re: [linux-audio-dev] n00b friendly latency tester
On Sat, 2006-05-06 at 04:19 +, carmen wrote: still cant get RT to boot AMD64 by any chance? What are the exact symptoms? Please send me your exact config (off list) Lee
Re: [linux-audio-dev] n00b friendly latency tester
On Sat, 2006-05-06 at 05:54 +0200, Dominic Sacré wrote: On Saturday, 6. May 2006 01:06, Lee Revell wrote: After some discussions at LAC I think a user friendly latency tester is needed so users have an easy way to test a setup, something better than than just installing apps and being mystified when they get tons of xruns. I think that would be very useful. Exactly what kind of latencies would this tool measure? Same as the existing CLI tools - it would start an RT thread that polls on the RTC, then tell the user to generate some load (switch windows, do a find /, pingflood the default gateway, whatever), then report back the maximum latency. The backend is trivial (there are a bunch of similar little tools out there), but I'm not a GUI person. Would anyone like to help design and implement this? Since time is money ;-) a simple Gnome and/or KDE front end would be the easiest way to start, and of course there should be a separation between the GUI and the back end so anyone can implement a leaner version if they want to. Anyone want to help with the GUI side? To me the GUI appears a lot more trivial than the backend :) So I'd like to offer my help writing a GTK frontend (steering clear of any particular Gnome/KDE dependencies). Are you going to make a fully functional command line version? I'd like to, this is why I said the GUI should be separate from the back end. I don't have the bandwidth to do the whole thing - I need someone (or a few people) to make a mockup GUI and then I'll wire up the buttons. Lee
[linux-audio-dev] n00b friendly latency tester
After some discussions at LAC I think a user friendly latency tester is needed so users have an easy way to test a setup, something better than than just installing apps and being mystified when they get tons of xruns. The backend is trivial (there are a bunch of similar little tools out there), but I'm not a GUI person. Would anyone like to help design and implement this? Since time is money ;-) a simple Gnome and/or KDE front end would be the easiest way to start, and of course there should be a separation between the GUI and the back end so anyone can implement a leaner version if they want to. Anyone want to help with the GUI side? Lee
Re: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard
On Wed, 2006-05-03 at 03:37 -0400, [EMAIL PROTECTED] wrote: OS embedded Linux to start with (at least until design is proofed) a true RTOS would be preferable Linux with the -rt patch is a true RTOS. Lee
Re: [linux-audio-dev] LADSPA Repository
On Thu, 2006-04-20 at 21:48 +0200, Lars Luthman wrote: How about a machine-friendly interface for searching and downloading plugin tarballs (or references to distribution packages) so one could write a tool like CPAN for LADSPAs? Wouldn't this have the same problem of poor integration with the distro's package management that CPAN has? How about just getting the distros to package all the useful plugins? Lee
Re: [linux-audio-dev] [ANN] netjack-0.11
On Sun, 2006-04-16 at 23:22 +0200, [EMAIL PROTECTED] wrote: Work is underway in improving the latency for big channel counts, like 24in / 24out. There seems to be a bottleneck in the kernels handling of big UDP Packets. Nice, I'm looking forward to the LKML thread! (you do plan to report it right...?)
Re: [linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR
On Tue, 2006-04-11 at 16:04 -0700, Lance Blisters wrote: I bought a Layla24 and Cardbus adaptor. Works beatifully with ALSA/JACK/ARDOUR up to 8 channels. However, the soundcard presents the 8 analog channels as device 0 and 8 digital channels as device 1. JACK will only open one device at a time. So in order to record and play back 16 channels with Ardour, I apparently need to create a virtual ALSA device combining the two LAYLA subdevices. Well, you certainly should have asked about it before getting this upset... So both devices are 8 channels full duplex? Lee
Re: [linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR
On Tue, 2006-04-11 at 16:04 -0700, Lance Blisters wrote:
I bought a Layla24 and Cardbus adaptor. Works beatifully with
ALSA/JACK/ARDOUR up to 8 channels. However, the soundcard presents the 8
analog channels as device 0 and 8 digital channels as device 1. JACK will
only open one device at a time. So in order to record and play back 16
channels with Ardour, I apparently need to create a virtual ALSA device
combining the two LAYLA subdevices.
Does this work? (based on
http://www.sound-man.co.uk/linuxaudio/ice1712multi.html)
# .asoundrc for layla
#
# Create virtual devices out of multiple subdevices
# JACK will need MMAP_COMPLEX support to use this.
pcm.multi_capture {
type multi
slaves.a.pcm hw:0,0
slaves.a.channels 8
slaves.b.pcm hw:0,1
slaves.b.channels 8
# First 8 channels of first soundcard (capture)
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave a
bindings.2.channel 2
bindings.3.slave a
bindings.3.channel 3
bindings.4.slave a
bindings.4.channel 4
bindings.5.slave a
bindings.5.channel 5
bindings.6.slave a
bindings.6.channel 6
bindings.7.slave a
bindings.7.channel 7
# First 8 channels of second soundcard (capture)
bindings.8.slave b
bindings.8.channel 0
bindings.9.slave b
bindings.9.channel 1
bindings.10.slave b
bindings.10.channel 2
bindings.11.slave b
bindings.11.channel 3
bindings.12.slave b
bindings.12.channel 4
bindings.13.slave b
bindings.13.channel 5
bindings.14.slave b
bindings.14.channel 6
bindings.15.slave b
bindings.15.channel 7
}
ctl.multi_capture {
type hw
card 0
}
pcm.multi_playback {
type multi
slaves.a.pcm hw:0,0
slaves.a.channels 8
slaves.b.pcm hw:0,1
slaves.b.channels 8
# First 8 channels of first soundcard (playback)
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave a
bindings.2.channel 2
bindings.3.slave a
bindings.3.channel 3
bindings.4.slave a
bindings.4.channel 4
bindings.5.slave a
bindings.5.channel 5
bindings.6.slave a
bindings.6.channel 6
bindings.7.slave a
bindings.7.channel 7
# First 8 channels of second soundcard (playback)
bindings.8.slave b
bindings.8.channel 0
bindings.9.slave b
bindings.9.channel 1
bindings.10.slave b
bindings.10.channel 2
bindings.11.slave b
bindings.11.channel 3
bindings.12.slave b
bindings.12.channel 4
bindings.13.slave b
bindings.13.channel 5
bindings.14.slave b
bindings.14.channel 6
bindings.15.slave b
bindings.15.channel 7
}
ctl.multi_playback {
type hw
card 0
}
Re: [linux-audio-dev] [ot] How do GUI-libs notify the program of changes?
On Mon, 2006-04-10 at 20:07 -0400, Dave Robillard wrote: and, of course, for great justice. Take off every sigc! Ah, ZeroWing - Internet meme zero. I can't believe it's been 5 years... Lee
Re: [linux-audio-user] Re: [linux-audio-dev] music engine
On Fri, 2006-04-07 at 13:43 -0400, Dave Robillard wrote: Apps really don't have to be designed with 64 bit compatibility in mind - it should be rather simple to port them. You'd be surprised at the shit people come up with ;) -Wall should not be optional http://www.thedailywtf.com/ Lee
Re: [linux-audio-user] Re: [linux-audio-dev] music engine
On Sat, 2006-04-08 at 03:04 +, carmen wrote: what advantage does it serve other than insulating yourself against the external API (ALSA dying in 6 months? i think not..) I found this very interesting: http://lurkertech.com/linuxvideoio.html It seems as if ALSA+JACK does exactly what this SGI engineer recommends (just give me the data!) while gstreamer does the opposite... Lee
Re: [linux-audio-dev] music engine
On Thu, 2006-04-06 at 04:14 -0800, Patrick Stinson wrote: I've been looking for a high-performance music engine. It must have an asynchronous control (socket, pipe?) mechanism to seperate the application from the audio thread. I'm looking for: start/stop samples on the beat scaled tempo control across all samples volume effects? easily wrappable (I'll write extensions, implement protocol plugins...) with python I'm trying to write something like ableton live without writing an engine all over again. FMODex would be *perfect* if it had a well-defined tempo/beat/sync interface. I think FreeWheeling might be the closest thing to Live that exists for Linux, have you looked at it? Lee
Re: [linux-audio-dev] multiface latency question
On Thu, 2006-04-06 at 20:52 +0200, fons adriaensen wrote: Have you been able to use -p 64 with 2.6.16 on the Thinkpad with ACPI ? I had no problems with it on my R51 when using 2.6.8 (SuSE 9.2), but since 2.6.13 (SuSE 10.0) I have to disable it. Killing the modules doesn't help, but acpi=off on the kernel command line does. Same with 2.6.15-rt. APM doesn't seem to do any harm, so that's what I use now. I wonder if the new dbus things are causing this. I doubt it's related to dbus, it sounds more like an ACPI kernel bug was introduced. How exactly does it fail? Lee
Re: [linux-audio-dev] multiface latency question
On Thu, 2006-04-06 at 21:25 +0200, fons adriaensen wrote: Every 40 seconds I get a shower of timeouts in JACK, even when no clients are running. I suspected the battery check of course, but that is configured for a 60 second period, and it didn't do any harm before. Killing powersaved and friends doesn't help, so indeed it looks like a kernel bug. If you really want to solve this and are sure it broke between 2.6.12 and 2.6.13 you could do a git bisect to find the problem. If all you know is it broke between 2.6.8 and 2.6.13 - ugh ;-) BTW, I noticed your talk in the LAC2006 program just a few minutes ago. Looking forward to see you there ! Yep, looking forward to it myself! Lee
Re: [linux-audio-user] Re: [linux-audio-dev] music engine
On Thu, 2006-04-06 at 19:40 +, carmen wrote: Freewheeling is *so* unlike Live its hard to even link the two. Just for a start, Live is organized around a timeline, Freewheeling is not. Live does have a freewheeling mode.where you can basically turn on and off loops and fx, McMusic style. you can record the actions in this mode, and view them on the timeline.. Yeah, this is what I was referring to. I've never touched the sequencer view in Live. And, I don't think it's fair to call it McMusic - all I use Live for is an effects host for my guitar, because I like the builtin effects and it has by far the best interface of any audio app. Lee
