I would say that the realtime capabilities of alsa were fine. I help write/develop xine (xine.sf.net) which is a media player for linux. alsa provides us with perfect audio to video sync.
Our only requirement is to know how many samples are currently in the audio buffer. So, if we send another sample to the buffer, we can calculate exactly how long it will wait in the buffer before being played. For what type of real-time applications would this approach not work? Cheers James > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Browne > Sent: 22 November 2001 02:51 > To: Paul Davis; [EMAIL PROTECTED] > Subject: Re: [Alsa-devel] Restarting when in async mode > > > > >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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
