> >Well, it doesn't seem to be completely okay... I occasionally get the error > >"Initial write error: broken pipe" and it just shuts down (well, it actually > >just hangs because the incallback mutex is never cleared - I need a timeout > >in there) the callback if things get too much for the poor thing to take. I > >did also notice when running the pcm example in async mode, if I started > >moving scrollbars and the like in my KDE environment, continuous glitches > >came into the audio. > no suprise there. i imagine you were handling the "audio device ready" > SIGIO signal in the same thread as the GUI, right? common mistake #1.
Well, no... there is no GUI as such - this is an embedded application. Actually, correction - there is a GUI, but not on the PC. ;) All the stages are linked via. circular buffers, from input to output. I was under the impression that the "async" callback routine executes at effective "realtime" priority (it wouldn't make sense to have it any other way - why would Jaroslav bother implementing it otherwise?), and mine serves the purpose of picking off buffers as available, dumping them to the soundcard - the bare minimum for very low CPU usage. The disappointing thing is that the machine should get so overloaded by a simple window movement that it misses the SIGIO and falls over. I was under the impression this didn't happen under "real" operating systems, or so all those smart-arse Linux gurus would tell me... :) I know I need another thread even though there is little going on at the control level. I recognised this many months ago... just surprised at how badly Linux reacted to code which worked fine under Win9x. > >Even if I decide not to use async mode, I'm going to have to redo my code a > >bit more to work properly under Linux... while it was fine under Win9x-style > >multitasking, it's now dropping out all over the place... > i'm sad to say this, but most people don't have a clue about writing > real-time audio applications for linux (or POSIX systems in > general). the issues are subtle, some of them are complex. ALSA > doesn't address them, nor does it seek to (at least not at this time). Hmm... I thought the one the main reasons for ALSA was to introduce low-latency audio to Linux?! > i wrote JACK (http://jackit.sf.net/) partly to help with this. but > JACK is not finished yet, and sometimes it seems that an entire book > is needed. i've spent the last 3 years doing nothing (code-wise) but > writing real time audio+MIDI apps, and the accumulated information is > full of stuff that continually trips people up. Took a quick look at the website. Looks interesting. Could you send me a CVS snapshot? I don't have dialup on the Linux machine to access it via. CVS. > i don't know how to make specific suggestions in your case, because i > have no idea what to do. but as a general suggestion, you should join > the linux-audio-development mailing list, and read the source code of > lots of real time audio code. I'm on the LAD, and unfortunately am also on a fairly tight deadline! Of course, I don't have your extensive experience working with realtime audio on Linux, but I didn't see a whole lot of issues to deal with. Once the kernel is scheduling to my requirements, with (preferably) no services running, and the mandatory three threads (process = high, callback = realtime, control = low) of the app in place, there don't appear to be any problems. Latency is not critical... a total of up to 500ms is acceptable. Given that the system will spend 99% of its time operating from a non-realtime source, there is plenty of opportunity for buffering. The CPU is probably going to be a 1.2GHz Celeron-II. No shortage of grunt. When all of my code is optimised, I'm looking at maybe 40% max. utilisation... if I can't get it low enough after significant opt. work, I'll get the Intel compiler and maybe throw some SSE in there. > async mode is not the right choice for apps in that class: Well, logically, using realtime callbacks to generate buffers as and when the soundcard requires them is the _perfect_ choice for a realtime system. My same code works just fine using ASIO at low latency. Steinberg have come up with a simple API that does the business... it was a pleasure to work with. > it might work, but the code will need to be using threads anyway, so why bother? I was not aware of the method which ALSA employed to generate the callback - I just expected it to _work_ like it does in Win9x (optimistic, it would appear). Okay, ALSA async is dodgy... I won't use that mode, then. But at least Jaroslav has fixed it so it doesn't crash on shutdown now! - Tom. _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
