latency.c: some feature requests

latency.c: some feature requests

[Lee Revell]

While trying to use latency.c to test my full duplex device for the
emu10k1 driver I have found some problems with it.

The first thing that doesn't work is that latency.c sets the sample rate
to 22050Hz.  Both of my hw devices only support 48000Hz.  This is fixed
by not setting the sample rate at all, causing it to default to the
correct rate.

I also need the capture device interleaved and the playback device
noninterleaved.  latency.c does not support this at all, it just assumes
that all hardware supports interleaved format.

I thought about adding command line options but it should just do the
right thing by default because my hw devices only support one sample
rate and one access type.

Anyway since the alsa documentation constantly refers to this file,
sometimes in lieu of any other documentation, it really needs to be more
flexible.

-- 
Lee Revell <rlrevell@joe-job.com>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: latency.c: some feature requests

[Jaroslav Kysela]

On Sat, 27 Nov 2004, Lee Revell wrote:

> While trying to use latency.c to test my full duplex device for the
> emu10k1 driver I have found some problems with it.
> 
> The first thing that doesn't work is that latency.c sets the sample rate
> to 22050Hz.  Both of my hw devices only support 48000Hz.  This is fixed
> by not setting the sample rate at all, causing it to default to the
> correct rate.
> 
> I also need the capture device interleaved and the playback device
> noninterleaved.  latency.c does not support this at all, it just assumes
> that all hardware supports interleaved format.

Use default device (-D default and -P default) which automatically 
uses available parameters.

> I thought about adding command line options but it should just do the
> right thing by default because my hw devices only support one sample
> rate and one access type.
> 
> Anyway since the alsa documentation constantly refers to this file,
> sometimes in lieu of any other documentation, it really needs to be more
> flexible.

Why? It's really simple test tool. The command line arguments can fix all
problems. Perhaps, the code should point to 'default' device as default.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: latency.c: some feature requests

[Lee Revell]

On Sun, 2004-11-28 at 12:37 +0100, Jaroslav Kysela wrote:
> On Sat, 27 Nov 2004, Lee Revell wrote:
> 
> > While trying to use latency.c to test my full duplex device for the
> > emu10k1 driver I have found some problems with it.
> > 
> > The first thing that doesn't work is that latency.c sets the sample rate
> > to 22050Hz.  Both of my hw devices only support 48000Hz.  This is fixed
> > by not setting the sample rate at all, causing it to default to the
> > correct rate.
> > 
> > I also need the capture device interleaved and the playback device
> > noninterleaved.  latency.c does not support this at all, it just assumes
> > that all hardware supports interleaved format.
> 
> Use default device (-D default and -P default) which automatically 
> uses available parameters.
> 

This will not work because I need to use hw:0,3 for playback and hw:0,2
for capture.

> > I thought about adding command line options but it should just do the
> > right thing by default because my hw devices only support one sample
> > rate and one access type.
> > 
> > Anyway since the alsa documentation constantly refers to this file,
> > sometimes in lieu of any other documentation, it really needs to be more
> > flexible.
> 
> Why? It's really simple test tool. The command line arguments can fix all
> problems.

Noninterleaved devices are not supported at all.  The access method is
hardcoded to interleaved.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: latency.c: some feature requests

[Jaroslav Kysela]

On Sun, 28 Nov 2004, Lee Revell wrote:

> On Sun, 2004-11-28 at 12:37 +0100, Jaroslav Kysela wrote:
> > On Sat, 27 Nov 2004, Lee Revell wrote:
> > 
> > > While trying to use latency.c to test my full duplex device for the
> > > emu10k1 driver I have found some problems with it.
> > > 
> > > The first thing that doesn't work is that latency.c sets the sample rate
> > > to 22050Hz.  Both of my hw devices only support 48000Hz.  This is fixed
> > > by not setting the sample rate at all, causing it to default to the
> > > correct rate.
> > > 
> > > I also need the capture device interleaved and the playback device
> > > noninterleaved.  latency.c does not support this at all, it just assumes
> > > that all hardware supports interleaved format.
> > 
> > Use default device (-D default and -P default) which automatically 
> > uses available parameters.
> > 
> 
> This will not work because I need to use hw:0,3 for playback and hw:0,2
> for capture.

-P plughw:0,3 -C plughw:0,2

> > > I thought about adding command line options but it should just do the
> > > right thing by default because my hw devices only support one sample
> > > rate and one access type.
> > > 
> > > Anyway since the alsa documentation constantly refers to this file,
> > > sometimes in lieu of any other documentation, it really needs to be more
> > > flexible.
> > 
> > Why? It's really simple test tool. The command line arguments can fix all
> > problems.
> 
> Noninterleaved devices are not supported at all.  The access method is
> hardcoded to interleaved.

Yes, but alsa-lib will do the necessary conversion.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: latency.c: some feature requests

[Lee Revell]

On Sun, 2004-11-28 at 19:44 +0100, Jaroslav Kysela wrote:
> > Noninterleaved devices are not supported at all.  The access method is
> > hardcoded to interleaved.
> 
> Yes, but alsa-lib will do the necessary conversion.

OK, thanks.  One other thing I noticed is that latency.c doesn't mmap.
This would cause higher latencies compared to testing with JACK,
correct?

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: latency.c: some feature requests

[Jaroslav Kysela]

On Sun, 28 Nov 2004, Lee Revell wrote:

> On Sun, 2004-11-28 at 19:44 +0100, Jaroslav Kysela wrote:
> > > Noninterleaved devices are not supported at all.  The access method is
> > > hardcoded to interleaved.
> > 
> > Yes, but alsa-lib will do the necessary conversion.
> 
> OK, thanks.  One other thing I noticed is that latency.c doesn't mmap.
> This would cause higher latencies compared to testing with JACK,
> correct?

Yes, it's good point. Perhaps, the snd_pcm_mmap_readi/writei functions 
should be used to optimize copying.

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: latency.c: some feature requests

[Lee Revell]

On Sun, 2004-11-28 at 19:44 +0100, Jaroslav Kysela wrote:
> -P plughw:0,3 -C plughw:0,2

Thanks.  Here are the results.  Does this look OK to you?

It looks like the playback runs 64 frames ahead of the capture.  Do you
think this would be a problem from the application's perspective?

rlrevell@mindpipe:~/cvs/alsa-cvs-T3/alsa-lib/test$ ./latency -P plughw:0,3 -C plughw:0,2 -c 16 -r 48000
Scheduler set to Round Robin with priority 99...
Playback device is plughw:0,3
Capture device is plughw:0,2
Parameters are 48000Hz, S16_LE, 16 channels, non-blocking mode
Wanted tick time: 0us, poll mode: no
Loop limit is 1440000 frames, minimum latency = 64, maximum latency = 4096
Plug PCM: Copy conversion PCM
Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STDI still have not implemented synced start so it looks like the capture and playback are a little out of sync.  
channels     : 16
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 64
period_size  : 32
period_time  : 666
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 4
xfer_align   : 4
start_threshold  : 2147483647
stop_threshold   : 64
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Slave: Hardware PCM card 0 'Sound Blaster Audigy2' device 3 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : MMAP_NONINTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 16
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 64
period_size  : 32
period_time  : 666
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 4
xfer_align   : 4
start_threshold  : 2147483647
stop_threshold   : 64
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Plug PCM: Hardware PCM card 0 'Sound Blaster Audigy2' device 2 subdevice 0

Its setup is:
stream       : CAPTURE
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 16
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 64
period_size  : 32
period_time  : 666
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 4
xfer_align   : 4
start_threshold  : 2147483647
stop_threshold   : 64
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Trying latency 64 frames, 1333.333us, 1.333333ms (750.0000Hz)
Success
Playback:
*** frames = 1440080 ***
state       : RUNNING
trigger_time: 1101676443.293035000
tstamp      : 1101676473.295128000
delay       : 59
avail       : 5
avail_max   : 15
Capture:
*** frames = 1440016 ***
state       : RUNNING
trigger_time: 1101676443.293030000
tstamp      : 1101676473.295506000
delay       : 52
avail       : 52
avail_max   : 52
Maximum read: 32 frames
Maximum read latency: 666.667us, 0.666667ms (1500.0000Hz)
Playback time = 1101676443.293035, Record time = 1101676443.293030, diff = 5

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: latency.c: some feature requests

[Jaroslav Kysela]

On Sun, 28 Nov 2004, Lee Revell wrote:

> It looks like the playback runs 64 frames ahead of the capture.  Do you
> think this would be a problem from the application's perspective?

That's correct - it's the latency.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/