trouble changing period size on HDA_intel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'll give some background at the bottom of this message in case
someone can provide a nicer way of doing what I need ...
I'm trying to write a moderately low latency application in pyalsa
that's driven by events from a touchpad/graphics tablet. I have the
application working on an older machine but can't get it to run
sensibly on my DELL E4310 with an INTEL HDA audio system.  Here are
some details:
----------------------------------------------------------------------
> cat < /proc/asound/version 
Advanced Linux Sound Architecture Driver Version 1.0.22.1.

> aplay -v test.wav
Plug PCM: Rate conversion PCM (48000, sformat=S16_LE)
Converter: linear-interpolation
Protocol version: 10002
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 11025
  exact rate   : 11025 (11025/1)
  msbits       : 16
  buffer_size  : 3763
  period_size  : 235
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 235
  period_event : 0
  start_threshold  : 3763
  stop_threshold   : 3763
  silence_threshold: 0
  silence_size : 0
  boundary     : 1059190337362198528
Slave: Route conversion PCM (sformat=S32_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Slave: Soft volume PCM
Control: PCM Playback Volume
min_dB: -51
max_dB: 0
resolution: 256
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Slave: Direct Stream Mixing PCM
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Hardware PCM card 0 'HDA Intel' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : ENABLE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1073741824
  silence_threshold: 0
  silence_size : 1073741824
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 209737729
----------------------------------------------------------------------
Rather than demonstrate the problem with 60K of pyalsaaudio.c, I seem
to have generated the same problem with the following C fragment:
----------------------------------------------------------------------
#include <alsa/asoundlib.h>
#include <stdio.h>
main()
{
  snd_pcm_t *handle;
  int res,dir;
  unsigned int val;
  snd_pcm_format_t fmt;
  snd_pcm_uframes_t frames;
  snd_pcm_hw_params_t *hwparams;
  snd_pcm_uframes_t buffersize, flurgle;
  static snd_output_t *output = NULL;
  res = snd_pcm_open( &handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
  printf("pcm_open res= %d\n", res);
  snd_pcm_hw_params_alloca(&hwparams);
  snd_output_stdio_attach(&output, stdout, 0);
  res = snd_pcm_hw_params_any(handle, hwparams);
  printf("getting %d\n", res);
  printf("configuration space\n");
  snd_pcm_hw_params_dump (  hwparams, output);



    snd_pcm_hw_params_set_access(handle, hwparams, 
                                 SND_PCM_ACCESS_RW_INTERLEAVED);
    snd_pcm_hw_params_set_format(handle, hwparams, SND_PCM_FORMAT_S16_LE);
    snd_pcm_hw_params_set_channels(handle, hwparams, 
                                   2);
    dir = 0;
    snd_pcm_hw_params_set_rate(handle, hwparams, 44100, dir);
    snd_pcm_hw_params_set_period_size(handle, hwparams, 
                                      2205, dir);
    snd_pcm_hw_params_set_periods(handle, hwparams, 4, 0);
    
    /* Write it to the device */

res = snd_pcm_hw_params(handle, hwparams);
  printf("getting %d\n", res);
  printf("current configuration \n");
  snd_pcm_hw_params_dump (  hwparams, output);


  snd_pcm_close(handle);
}
----------------------------------------------------------------------
which produces the following result:
gcc alsatest.c -lasound
> a.out
pcm_open res= 0
getting 0
configuration space
ACCESS:  MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX RW_INTERLEAVED RW_NONINTERLEAVED
FORMAT:  S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW A_LAW IMA_ADPCM S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
SUBFORMAT:  STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: [4000 4294967295)
PERIOD_TIME: (21333 21334)
PERIOD_SIZE: (85 91628833)
PERIOD_BYTES: (42 4294967295)
PERIODS: (0 17247242)
BUFFER_TIME: [1 4294967295]
BUFFER_SIZE: [170 1466015503]
BUFFER_BYTES: [85 4294967295]
TICK_TIME: ALL
getting 0
current configuration 
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (21333 21334)
PERIOD_SIZE: (940 941)
PERIOD_BYTES: (3760 3764)
PERIODS: 4
BUFFER_TIME: (85328 85329)
BUFFER_SIZE: 3763
BUFFER_BYTES: 15052
TICK_TIME: 0
----------------------------------------------------------------------
You can see that the period_size didn't change, presumably because
this isn't a valid configuration somehow.
can I change the period_size on this device and can I change the
relationship between period_size and buffer_size (I thought this was
set by the "periods" parameter)

Background:
I'm a totally blind scientist who needs to study a lot of
2-dimensional data.  Long, long ago I wrote an application for a Next
(easily the best machine for programming sound/music I've ever used)
that would take the mouse coordinate, transform it into a point in the
array of 2d data, and synthesize a pure tone generated by that value.
All very nice except I couldn't get absolute position from the mouse,
not based on any physical frame of reference.  Graphics tablets were
too expensive in those days and didn't work with the Next.
Enter modern Linux laptops with touchpads.  Provided I can bully the
touchpad into reporting absolute coordinates I have everything I need.
A bright undergraduate intern wrote most of the python stuff and it
worked nicely on his test machine.  
But to make it work we needed to fiddle buffer_size and there seemed
relatively small windows that produced acceptable latency and
stability.  Any attempt to change buffer_size, period_size or damn
near anything else fails on my machine.  
there are a few constraints that *may* be contributing to the problem.
I can't just open the hardware device directly. I need to share sound
with a speech synthesizer that provides my interaction with the
machine, that's why I'm opening the "default" device above. 
We had other problems too to do with clicking as we changed waveforms
but careful choice of frequencies to avoid discontinuities has solved
that.
So my specific questions:
Have I hit a limitation of a hardware device or is there something
obviously wrong with the above code?
Is there another way within alsa of reducing the latency without
breaking the speech system? I'm happy to do things at boot-time to
reconfigure the hardware if necessary.
Is there another approach compatible with pyalsa that will avoid all
these problems?
With thanks to anyone who's read this far
Peter
-- 
Peter Rayner
room 330 
School of Earth Sciences, University of Melbourne, 3010, Vic, Australia
tel: work: +61 (0)3 8344 9708; fax: +61 (0)3 8344 7761 
mobile +61 402 752 379, skype: petermorag 
mail-to: prayner@xxxxxxxxxxxxxx

------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user


[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux