[alsa-devel] start_threshold and stream controls for PCM streams
Hi,
Would like to know how start_threshold is expected to be used in single_threaded audio player?
I assume that in blocking implementation, the write call will block till the ring buffer becomes empty. Is it right?
If the audio player has to wait for the write call to be blocked, I guess it is possible that the delay to service the stream controls will be delayed as long as the buffer duration.
If so, how can I send stream control operations for the stream when the stream is blocked for the buffer?
What are the option to service stream controls immediately?
Thanks in advance.
Thanks -Sing
At Fri, 9 Dec 2011 11:05:19 +0530, Nallasellan, Singaravelan wrote:
Hi,
Would like to know how start_threshold is expected to be used in single_threaded audio player?
I assume that in blocking implementation, the write call will block till the ring buffer becomes empty. Is it right?
Not really. It's not necessarily to be empty. The condition is that the empty space becomes avail_min or more.
But, this has nothing to do with start_threshold. The start_threshold is the value to start the stream automatically. When it's 1, the stream is started immediately when something is written. When it's buffer_size, the stream is started when all data is filled in the buffer.
And, the write-block behavior is irrelevant with start_threshold.
Takashi
2011/12/12, Takashi Iwai tiwai@suse.de:
At Fri, 9 Dec 2011 11:05:19 +0530, Nallasellan, Singaravelan wrote:
Hi,
Would like to know how start_threshold is expected to be used in single_threaded audio player?
I assume that in blocking implementation, the write call will block till the ring buffer becomes empty. Is it right?
Not really. It's not necessarily to be empty. The condition is that the empty space becomes avail_min or more.
But, this has nothing to do with start_threshold. The start_threshold is the value to start the stream automatically. When it's 1, the stream is started immediately when something is written. When it's buffer_size, the stream is started when all data is filled in the buffer.
And, the write-block behavior is irrelevant with start_threshold.
According to HDA specification
5.4.2 Link Sample Delivery Timing
HDA link is fixed at 48000Hz
For example, with a multiple of 4 (192 kHz sample rate), there must be four sample blocks transmitted in every frame on the link
Does it mean that start threshold cannot be 1 for rate higher than 48000Hz ?
Any special requirement of the period size for rate higher than 48000Hz ? (.e.g mutliple of two for 96000Hz or multiple of 4 for 192000Hz)
44.1-kHz Delivery Timings Since the link frame rate is fixed at 48 kHz, streams using a base rate of 44.1 kHz must have samples transmitted on a cadence creating the slightly lower aggregate transmission rate to match the slightly lower rendering rate. For streams running at a sample rate of 44.1 kHz, instead of transmitting one sample block in each frame (as happens for 48.0 kHz rate streams), there are occasional frames that will not contain a sample generating the following cadence. 12-11-11-12-11-11-12-11-11-12-11-11-11- (repeat)
In this cadence, the dashes indicate frames that do not contain a sample block. Therefore, there are 12 frames containing one sample block each, followed by one frame with no sample block, followed by 11 frames with one sample block each, etc. Following the empty frame at the end, the cadence repeats continuously generating exactly 147 sample blocks every 160 frames and avoiding any long-term drift between sample delivery and rendering clock.
Does it mean that the first 12 samples of 44100Hz are transmitted at 48000Hz ?
participants (3)
-
Nallasellan, Singaravelan
-
Raymond Yau
-
Takashi Iwai