> >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
> absolutely not. SIGIO is delivered to your process/thread just like
> any other signal.
Well, that's bugger all use, then... :)
> contemporaneous on Linux). how soon depends on the kernel. this is
> what the low latency (and preemption) patches are all about: reducing
> this delay in the running of a ready-to-run thread to the absolute
> bare minimum. however, even with those patches, without using
> SCHED_FIFO or SCHED_RR, the delay prohibits the system from being
> considered "realtime".
Why can't the scheduler be modified to support hard realtime? Isn't this
what RTX on NT and RTLinux offer?
> its not overloaded. there is a lot more to this than you're seeing,
> though i agree that there should not be. there are, for example,
> problems with the interaction between some video interfaces
I've tried taking the videocard (almost) and X out of the equation. Didn't
help that much.
> the PCI bus
Shouldn't stall to a degree to cause dropouts. I'm talking buffers >10ms
here...
> >Once the kernel is scheduling to my requirements, with (preferably) no
> right, but this is not a trivial thing. interactions between the VM
When you say VM, do you mean Virtual Machine or Virtual Memory? I certainly
don't use vmem, and I don't see why anyone would need to these days...
> system and the scheduler have caused constant headaches in this area
> for a long time. its distinctly non-trivial to get an application
> in which a certain block of code will be executed at the right time,
> on time, every time. it can be done, for sure, but its not trivial,
> and it has complications in that it requires either root permissions
No problem for an embedded system. The concept of multi-user doesn't apply.
> or a kernel built with capabilities enabled and a program that can
> grant CAP_RESOURCE. why? how does the kernel know that your program
> won't simply take over the machine?
Can't we operate on a "trust-me" basis? :)
> >Latency is not critical... a total of up to 500ms is acceptable. Given
that
> Not much hardware can offer than much. A typical limit is on the order
> of 8k to 16k frames of audio.
The hardware doesn't have to support it - I was talking many small buffers.
It is merely protection against things such as hard drive fragmentation,
ensuring that the callback always has a number of buffers waiting to be
output. Since the source is non-realtime, it can comfortably catch up once
the trouble is over...
> BTW, most of us wouldn't consider this
> even in the realm of low latency, which for most people means
> something like 1-5msecs.
Obviously. But that has no use for me right now. Besides, <3ms is pretty
much impossible with PC architecture when you have more than one device on
the PCI bus. Like a soundcard and a hard drive controller. :)
HyperTransport should sort that out.
> thread 1:
>
> while (1) {
> wait_for_disk_data_needed();
> fill_buffers ();
> }
>
> thread 2:
>
> while (1) {
> wait_for_audio_to_be_possible ();
> write_to_audio_interface_from_buffers ();
> }
>
> well, that looks better, except if the implementation of
> fill_buffers() and write_to_audio_interface_from_buffers() uses a
> mutex
You wouldn't, though! As I said, with a few circular buffers at each stage,
asynchronous processing should always be possible. At the sort of latencies
I'm aiming for (500ms was worst case... let's say 100ms is the target), only
the scheduling can let me down.
> >Well, logically, using realtime callbacks to generate buffers as and when
> >the soundcard requires them is the _perfect_ choice for a realtime
system.
> true. but thats not what you're doing. what you're doing is getting
> the driver to generate POSIX signals that are delivered to your
> process.
I know that now. :)
> if you use poll(2) for synchronous notification, things will work
> pretty much the way they do under ASIO. better actually, though ALSA
> doesn't wrap the use of poll(2) in any particularly pretty clothing.
I'll have to look into it... is there any sources I should look at now to
start moving on this, before the JACK tarball is released next week?
- Tom.
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
