0

Problem statement: I do not receive the entire song in the output when dumped as a file (I can't hear the song through the jack but I could dump the file contents).

excerpts: I am new to ALSA programming and I have an embedded board with limited set of commands. I have gone through the links here: ALSA tutorial required but I couldn't figure out this timing related issues.

Setup: 

OS: linux 4.14.70
aplay: version 1.1.4 by Jaroslav Kysela <perex@perex.cz>
Advanced Linux Sound Architecture Driver Version k4.14.70.

The audio box involved has a separate hardware and a separate DSP for stand alone processing

Flow of information: Linux -> DSP core

The input song is communicated to the linux core, loading the song into DMA area -> Read DMA into separate DMA ring buffer area used by the DSP and write it to I2S output path into a file

I could see the size of the song is 960000 Bytes, with sample rate of 48000, S16_LE formwat, 2 channel, 16 bit bit-depth -> which calculates as shown below - as per the page "https://www.colincrawley.com/audio-duration-calculator/"

Bit Rate: 1536 kbps
Duration: 
0 Hours : 0 Minutes : 5 Seconds . 34 Milliseconds

As I put the logs, my DSP core is processing the song only for a period of approx. 1 second before "aplay" application sends an ioctl call to close the audio interface on the linux.

My questions are:

  1. How does aplay understand time ? For a 5 seconds time, how could we be sure that it has run for a period of 5 seconds.
  2. Is there a way to understand to wait until entire song is transmitted to the DSP core to process before the close IOCTL command is issued?

Some more info about the input file I am feeding:

  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 24000
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 6755399441055744000
  appl_ptr     : 0
  hw_ptr       : 0

I would be happy to provide more information into understanding why the aplay application closes the song early. But please be aware that its a closed-source project.

Command I use:

aplay input.wav -c 2 -r 48000 -t wav

input size: 960044 bytes (including wav header)
output size: 306 KB observed before IOCTL call to close the audio interface occurs.

For a input.wav file of 960044 file size i.e., 938 KB,

time aplay input.wav returns:

real    0m0.988s
user    0m0.012s
sys     0m0.080s

To find the duration of wav file:

fileLength/(sampleRate*channel*bits per sample/8) = 960000/((48000 * 2 * 16)/8) = 5 seconds


If I run the same song on my Ubuntu machine, it is as expected:

real    0m5.452s
user    0m0.025s
sys 0m0.029s

Any hints on why this could occur ? As seen above, I could see the aplay applications quits in 0.98 seconds. But the song has to be played for 5 seconds.

Adit Ya
  • 731
  • 1
  • 8
  • 19
  • its not clear just what you are doing however if your code is executing aplay and that aplay child process seems to be exiting too early my guess is it has correctly rendered its input audio file and sent its output audio to the system which has buffered it ... alternative would be to eliminate use of aplay and write your own audio render – Scott Stensland May 09 '19 at 11:14
  • Am testing the entire audio hardware and in the process when it comes to playing the audio input and check its fidelity, I see the aplay application quits way before entire audio is dumped in the output path, making me confused where the problem would be. – Adit Ya May 09 '19 at 14:48

1 Answers1

0

Looks like there was some problem with the custom audio hardware that was delaying the timing to process the song. It now seems to be fixed. Basically put, the sound hardware has to give sufficient delays atleast as per AXI protocol as the bytes are being read. But in this case, it is not so. Its now resolved. Thanks for the attention

Adit Ya
  • 731
  • 1
  • 8
  • 19