(stupid me.. again for the list...)

Hi,

2012/5/9 Takashi Iwai tiwai@suse.de:

Or a full-duplex issue? You can test the latency via alsa-lib/test/latency program.

OK, I don't know if I'm using it the right way (see below ) but here are some observations:

1. With the old streaming logic I can successfully go down to a reported latency of 384 frames @96kHz without an xrun.

2. With the new streaming logic 'latency' will not start.

It fails with: Unable to set hw params for capture: Device or resource busy Unable to set sw parameters for playback stream: Device or resource busy

As a first guess this could be related to the fact that the PCM streams of the FTU are never reported as "Running" with the new streaming logic. (Daniel?)

3. 'latency' never returns cleanly.

On Ubuntu I'm getting *** glibc detected *** /home/fex/workspace/Audio/Latency/alsa-lib/test/.libs/lt-latency: invalid fastbin entry (free): 0x00000000013c0570 ***

On Fedora (kernel with old streaming logic) I get:

*** glibc detected *** /home/fex/workspace/Audio/Latency/alsa-lib/test/.libs/lt-latency: munmap_chunk(): invalid pointer: 0x00000000018a5f90 *** *** glibc detected *** /home/fex/workspace/Audio/Latency/alsa-lib/test/.libs/lt-latency: malloc(): memory corruption (fast): 0x00000000018a5a90 ***

On Fedora 'latency' hangs after this message.

(Yes, the usage is quite undocumented. Anyone contributing the howto would be great...)

Yes, I don't even know how to use it or if I've used it correctly...

It doesn't seem to be neccessary to connect an output to an input. Is this correct? At least results don't change without a connection...

Regards,

Felix