Handle large period size end-of-stream situation

Handle large period size end-of-stream situation

[Patrick Lai]

Hi,

I am dealing with a use case requiring passing large buffer down to the
DSP. Application in the user-space passes PCM through mmap interface.
Per my understanding, ALSA is designed to work with DMA. Data is
transferred in chunk equal to period size. At the end of playback,
there may not be enough audio data left in the music stream to fill
entire period. If remaining audio data only takes up very small chunk
of period, playback takes longer to stop. Given that period size I have
to deal with is quite large, this problem is observed easily. If my
understanding is correct, what is the standard/recommended way of
handling end of stream case?

Thanks
Patrick

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Handle large period size end-of-stream situation

[Clemens Ladisch]

Patrick Lai wrote:
> Data is transferred in chunk equal to period size.

Data is transferred in whatever chunk size the hardware uses.

The period size specifies when the hardware raises an interrupt.
If some application is blocking, this interrupt is the only mechanism
by which userspace is woken up.

> At the end of playback, there may not be enough audio data left in the
> music stream to fill entire period. If remaining audio data only takes
> up very small chunk of period, playback takes longer to stop. Given
> that period size I have to deal with is quite large, this problem is
> observed easily. If my understanding is correct, what is the standard/
> recommended way of handling end of stream case?

I guess you wouldn't ask if your hardware supported smaller periods? ;-)

Use non-blocking writes, and use some other timer to wait for the actual
data to be played.  (But if the hardware cannot report the current
playback position accurately, ALSA won't notice that the playback has
reached the end.)


Regards,
Clemens

Re: Handle large period size end-of-stream situation

[Patrick Lai]

On 4/3/2013 9:49 AM, Clemens Ladisch wrote:
> Patrick Lai wrote:
>> Data is transferred in chunk equal to period size.
>
> Data is transferred in whatever chunk size the hardware uses.
>
> The period size specifies when the hardware raises an interrupt.
> If some application is blocking, this interrupt is the only mechanism
> by which userspace is woken up.
>
>> At the end of playback, there may not be enough audio data left in the
>> music stream to fill entire period. If remaining audio data only takes
>> up very small chunk of period, playback takes longer to stop. Given
>> that period size I have to deal with is quite large, this problem is
>> observed easily. If my understanding is correct, what is the standard/
>> recommended way of handling end of stream case?
>
> I guess you wouldn't ask if your hardware supported smaller periods? ;-)

The hardware can accept smaller period but smaller period would result
in more frequent interrupt to application processor. This leads to
higher power consumption.

>
> Use non-blocking writes, and use some other timer to wait for the actual
> data to be played.  (But if the hardware cannot report the current
> playback position accurately, ALSA won't notice that the playback has
> reached the end.)

My concern is not about blocking too long but audio playback ending 
longer than necessary. If I understand correctly, you are suggesting 
that application, once done transferring residual data, set up timer 
according to expected duration of residual data. Upon waking up from 
timer, call ALSA library API to get the current hardware pointer.
Is my understanding correct?

>
>
> Regards,
> Clemens
>


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Handle large period size end-of-stream situation

[Gabriel M. Beddingfield]

On 04/03/2013 08:07 AM, Patrick Lai wrote:
> I am dealing with a use case requiring passing large buffer down to the
> DSP. Application in the user-space passes PCM through mmap interface.
> Per my understanding, ALSA is designed to work with DMA. Data is
> transferred in chunk equal to period size. At the end of playback,
> there may not be enough audio data left in the music stream to fill
> entire period. If remaining audio data only takes up very small chunk
> of period, playback takes longer to stop. Given that period size I have
> to deal with is quite large, this problem is observed easily. If my
> understanding is correct, what is the standard/recommended way of
> handling end of stream case?

In the typical end-of-stream case, you simply write the data that you 
have.  When the hw pointer catches up to the application pointer, you 
get an XRUN and the stream stops immediately.  There's no requirement 
that streams have to stop on period boundaries.

-gabriel

Re: Handle large period size end-of-stream situation

[Clemens Ladisch]

Gabriel M. Beddingfield wrote:
> In the typical end-of-stream case, you simply write the data that you
> have.  When the hw pointer catches up to the application pointer, you
> get an XRUN and the stream stops immediately.

But that happens only when ALSA actually reads the hardware pointer.
The application could ask for the pointer position for some reason, but
when it is blocked, only the end-of-period interrupt will cause that.


Regards,
Clemens

Re: Handle large period size end-of-stream situation

[Gabriel M. Beddingfield]

On 04/04/2013 02:27 AM, Clemens Ladisch wrote:
> Gabriel M. Beddingfield wrote:
>> In the typical end-of-stream case, you simply write the data that you
>> have.  When the hw pointer catches up to the application pointer, you
>> get an XRUN and the stream stops immediately.
>
> But that happens only when ALSA actually reads the hardware pointer.
> The application could ask for the pointer position for some reason, but
> when it is blocked, only the end-of-period interrupt will cause that.

I stand corrected.  (Thanks also to Peter Ujfalusi for setting me straight.)

So, if the hardware can detect it then the hardware needs to signal an 
interrupt for the XRUN.

Another option... from userspace you can call SYNC_PTR (e.g. 
pcm_get_htimestamp() in tinyalsa) to update the hw and application 
pointers, then inspect them to detect when all the data is transferred. 
  When you see all is played, immediately stop the stream.  Again, this 
presumes that the "hw" side is able to query the state of the pointer.

-gabriel

Re: Handle large period size end-of-stream situation

[Clemens Ladisch]

Gabriel M. Beddingfield wrote:
> So, if the hardware can detect it then the hardware needs to signal an interrupt for the XRUN.

The hardware typically doesn't know the application pointer.

> Another option... from userspace you can call SYNC_PTR (e.g.
> pcm_get_htimestamp() in tinyalsa) to update the hw and application
> pointers, then inspect them to detect when all the data is transferred.
> When you see all is played, immediately stop the stream.

ALSA checks for xruns before returning the pointer.  It's enough to just
ask for the pointer (or the state).


Regards,
Clemens