FramesPeriods - Revision history

Sdaau: /* Additional example */ - added mailing list quote

2010-11-04T23:27:20Z

Additional example: - added mailing list quote

← Older revision		Revision as of 23:27, 4 November 2010
Line 39:		Line 39:
	It seems ([http://mirror.leaseweb.com/kernel/people/tiwai/docs/writing-an-alsa-driver.pdf writing-an-alsa-driver.pdf]), however, that it is the ALSA runtime that decides on the actual ''buffer_size'' and ''period_size'', depending on: the requested number of channels, and their respective properties (rate and sampling resolution) - as well as the parameters set in the ''snd_pcm_hardware'' structure (in the driver).		It seems ([http://mirror.leaseweb.com/kernel/people/tiwai/docs/writing-an-alsa-driver.pdf writing-an-alsa-driver.pdf]), however, that it is the ALSA runtime that decides on the actual ''buffer_size'' and ''period_size'', depending on: the requested number of channels, and their respective properties (rate and sampling resolution) - as well as the parameters set in the ''snd_pcm_hardware'' structure (in the driver).

			Also, the following quote may be relevant, from "[http://mailman.alsa-project.org/pipermail/alsa-devel/2007-April/000474.html (alsa-devel) Questions about writing a new ALSA driver for a very limitted device]":
			<pre>
			> > The "frame" represents the unit, 1 frame = # channels x sample_bytes.
			> > In your case, 1 frame corresponds to 2 channels x 16 bits = 4 bytes.
			> >
			> > The periods is the number of periods in a ring-buffer. In OSS, called
			> > as "fragments".
			> >
			> > So,
			> > - buffer_size = period_size * periods
			> > - period_bytes = period_size * bytes_per_frame
			> > - bytes_per_frame = channels * bytes_per_sample
			> >
			>
			> I still don't understand what 'period_size' and a 'period' is?

			The "period" defines the frequency to update the status, usually via
			the invokation of interrupts. The "period_size" defines the frame
			sizes corresponding to the "period time". This term corresponds to
			the "fragment size" on OSS. On major sound hardwares, a ring-buffer
			is divided to several parts and an irq is issued on each boundary.
			The period_size defines the size of this chunk.

			On some hardwares, the irq is controlled on the basis of a timer. In
			this case, the period is defined as the timer frequency to invoke an
			irq.
			</pre>

	----		----

Sdaau: added additional example section

2010-11-04T22:29:48Z

added additional example section

← Older revision		Revision as of 22:29, 4 November 2010
Line 8:		Line 8:

	Now, if the hardware has been set to 48000Hz , 2 periods, of 1024 frames each, making a buffer size of 2048 frames. The hardware will interrupt 2 times per buffer. ALSA will endeavor to keep the buffer as full as possible. Once the first period of samples has been played, the third period of samples is transfered into the space the first one occupied while the second period of samples is being played. (normal ring buffer behaviour).		Now, if the hardware has been set to 48000Hz , 2 periods, of 1024 frames each, making a buffer size of 2048 frames. The hardware will interrupt 2 times per buffer. ALSA will endeavor to keep the buffer as full as possible. Once the first period of samples has been played, the third period of samples is transfered into the space the first one occupied while the second period of samples is being played. (normal ring buffer behaviour).



			== Additional example ==

			Here is an alternative example for the above discussion.

			Say we want to work with a stereo, 16-bit, 44.1 KHz stream, ''one-way'' (meaning, ''either'' in playback ''or'' in capture direction). Then we have:
			* 'stereo' = '''number of channels''': 2
			* 1 '''analog sample''' is represented with 16 bits = 2 bytes
			* 1 '''frame''' represents 1 analog sample from all channels; here we have 2 channels, and so:
			** 1 frame = (num_channels) * (1 sample in bytes) = (2 channels) * (2 bytes (16 bits) per sample) = 4 bytes (32 bits)
			* To sustain 2x 44.1 KHz '''analog rate''' - the system must be capable of '''data transfer rate''', in Bytes/sec:
			** Bps_rate = (num_channels) * (1 sample in bytes) * (analog_rate) = (1 frame) * (analog_rate) = ( 2 channels ) * (2 bytes/sample) * (44100 samples/sec) = 2244100 = 176400 Bytes/sec ([http://latex.codecogs.com/png.latex?\begin{array}{ccc}&space;Bps\_rate&space;&=&space;(analog\_rate)&space;&\cdot&space;(num\_channels)&space;\cdot&space;(1\&space;\text{sample&space;(as&space;bytes)})&space;\\&space;&=&space;(analog\_rate)&space;&\cdot&space;(1\&space;\text{frame})&space;\\&space;&=&space;(44100\&space;\frac{\text{samples}}{\text{sec}})&space;&\cdot&space;(&space;2\&space;\text{channels}&space;)&space;\cdot&space;(2\&space;\frac{\text{bytes}}{\text{sample}})&space;\\&space;&=&space;(44100\&space;\frac{\text{frames}}{\text{sec}})&space;&\cdot&space;(4\&space;\frac{\text{bytes}}{\text{frame}})&space;\\&space;&=&space;176400\&space;\frac{\text{bytes}}{\text{sec}}&space;\end{array} link to formula img])


			[[Image:alsa_bps_formula.png\|frame\|center\|Alsa Bps formula]]


			Now, if ALSA would interrupt each second, asking for bytes - we'd need to have 176400 bytes ready for it (at end of each second), in order to sustain analog 16-bit stereo @ 44.1Khz.
			* If it would interrupt each half a second, correspondingly for the same stream we'd need 176400/2 = 88200 bytes ready, at each interrupt;
			* if the interrupt hits each 100 ms, we'd need to have 176400*(0.1/1) = 17640 bytes ready, at each interrupt.


			We can control when this PCM interrupt is generated, by setting a ''period size'', which is set in ''frames''.
			* Thus, if we set 16-bit stereo @ 44.1Khz, and the period_size to 4410 frames => (<small>for 16-bit stereo @ 44.1Khz, 1 frame equals 4 bytes - so 4410 frames equal 4410*4 = 17640 bytes</small>) => an interrupt will be generated each 17640 bytes - that is, each 100 ms.
			* Correspondingly, buffer_size should be at least 2period_size = 24410 = 8820 frames (or 8820*4 = 35280 bytes).


			It seems ([http://mirror.leaseweb.com/kernel/people/tiwai/docs/writing-an-alsa-driver.pdf writing-an-alsa-driver.pdf]), however, that it is the ALSA runtime that decides on the actual ''buffer_size'' and ''period_size'', depending on: the requested number of channels, and their respective properties (rate and sampling resolution) - as well as the parameters set in the ''snd_pcm_hardware'' structure (in the driver).



	----		----

Y2kbug: remove unnecessary link

2007-08-11T17:32:19Z

remove unnecessary link

← Older revision		Revision as of 17:32, 11 August 2007
Line 10:		Line 10:

	----		----
	[https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=FramesPeriods original] created [[2006-09-24]] by [[User:JamesCourtierDutton]]		[https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=FramesPeriods original] created 2006-09-24 by [[User:JamesCourtierDutton]]

	[[Category:Development]] [[Category:MigratedFromDev]]		[[Category:Development]] [[Category:MigratedFromDev]]

EliotBlennerhassett at 23:09, 6 August 2007

2007-08-06T23:09:25Z

← Older revision		Revision as of 23:09, 6 August 2007
Line 9:		Line 9:
	Now, if the hardware has been set to 48000Hz , 2 periods, of 1024 frames each, making a buffer size of 2048 frames. The hardware will interrupt 2 times per buffer. ALSA will endeavor to keep the buffer as full as possible. Once the first period of samples has been played, the third period of samples is transfered into the space the first one occupied while the second period of samples is being played. (normal ring buffer behaviour).		Now, if the hardware has been set to 48000Hz , 2 periods, of 1024 frames each, making a buffer size of 2048 frames. The hardware will interrupt 2 times per buffer. ALSA will endeavor to keep the buffer as full as possible. Once the first period of samples has been played, the third period of samples is transfered into the space the first one occupied while the second period of samples is being played. (normal ring buffer behaviour).

	---		----
	[https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=FramesPeriods original] created [[2006-09-24]] by [[User:JamesCourtierDutton]]		[https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=FramesPeriods original] created [[2006-09-24]] by [[User:JamesCourtierDutton]]

	[[Category:Development]] [[Category:MigratedFromDev]]		[[Category:Development]] [[Category:MigratedFromDev]]

EliotBlennerhassett: migrate from dev

2007-08-06T23:09:01Z

migrate from dev

New page

A frame is equivalent of one sample being played, irrespective of the number of channels or the number of bits. e.g.
* 1 frame of a Stereo 48khz 16bit PCM stream is 4 bytes.
* 1 frame of a 5.1 48khz 16bit PCM stream is 12 bytes.

A period is the number of frames in between each hardware interrupt. The poll() will return once a period.

The buffer is a ring buffer. The buffer size always has to be greater than one period size. Commonly this is 2*period size, but some hardware can do 8 periods per buffer. It is also possible for the buffer size to not be an integer multiple of the period size.

Now, if the hardware has been set to 48000Hz , 2 periods, of 1024 frames each, making a buffer size of 2048 frames. The hardware will interrupt 2 times per buffer. ALSA will endeavor to keep the buffer as full as possible. Once the first period of samples has been played, the third period of samples is transfered into the space the first one occupied while the second period of samples is being played. (normal ring buffer behaviour).

---
[https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=FramesPeriods original] created [[2006-09-24]] by [[User:JamesCourtierDutton]]

[[Category:Development]] [[Category:MigratedFromDev]]