It really blew my mind when Paul Davis <[EMAIL PROTECTED]> said:
> >> unless you can figure out what the interesting address ranges are and
> >> then find only the assignments to locations within those ranges, no
> >> debugger or anything will help reverse engineer this kind of design.
> >
> >Ah,
On Thu, 2001-11-08 at 07:31, Maarten de Boer wrote:
> Not understanding why I could not get alsa-lib/test/latency.c to work
> well, I decided to run Benno's latency test. It has been a long time
> since I did... The results are surprising, and nothing like the excellent
> results I have seen poste
>> unless you can figure out what the interesting address ranges are and
>> then find only the assignments to locations within those ranges, no
>> debugger or anything will help reverse engineer this kind of design.
>
>Ah, but we can (with PCI at least). /proc/pci is your friend.
Ah, but you can
On Wed, 2001-11-07 at 19:27, Paul Davis wrote:
>
> Ah, OK. yes, i suppose this might not be clear.
>
> when you set the size of a "period" in ALSA, you are basically setting
> the interval at which the h/w will interrupt the host system to notify
> it that space/data is available. so, if you set
Not understanding why I could not get alsa-lib/test/latency.c to work
well, I decided to run Benno's latency test. It has been a long time
since I did... The results are surprising, and nothing like the excellent
results I have seen posted here.
$ ./do_tests none 3 128 0 256
http://193.145.55.36
>I don't agree with Paul that the latency.c test program is not a good
>example for testing and showing the capture -> process -> play circle
>required by some applications.
applications that do this will need to be multithreaded if they have
any UI at all (i.e. anything involving real-time cont
> if you call poll(2) on the file descriptors returned by
> snd_pcm_poll_descriptors() (and there may be more than one for some
> kinds of PCM "devices"), then what you're actually doing is this:
Hmm, isn't this _exactly_ what the latency test does in poll mode?
(using snd_pcm_wait, which does po
Paul Davis wrote:
> Ah, OK. yes, i suppose this might not be clear.
> [...]
But you made it completely clear now! Thank you very much, Paul.
Paul Davis wrote also:
> but its basically fairly easy to get this performance out of
> any program that is engineered properly. latency.c is not the
> cor
