aplay quits before entire song is read - linux

Question

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:
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.
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.

Answer 1

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