DynamicAudioRateSpec

Differences between revisions 2 and 3
Revision 2 as of 2006-11-06 06:45:32
Size: 1654
Editor: 72
Comment:
Revision 3 as of 2006-11-06 07:23:12
Size: 2519
Editor: 72
Comment:
Deletions are marked like this. Additions are marked like this.
Line 17: Line 17:
High definition audio is starting to become more common. A desktop user should not be required to choose between utilizing a sample rate higher than 44100 and having software mixing available. High definition audio is starting to become more common. A desktop user should not be required to choose between utilizing a sample rate higher than 44100 and having software mixing available.  A sound server that can provide dynamic sample rates is also a must for professional audio applications if they are to coexist with other desktop sound events (e.g., Gaim).
Line 21: Line 21:
1. Single  1. No client connected, new client connects: rate = min(client_rate, max_hardware_rate)

 2. At least one active client, new client connects or existing client disconnects: rate = min(max(client_rates), max_hardware_rate)
Line 26: Line 28:

I understand that Ubuntu is considering switching to [http://pulseaudio.org/ Pulse Audio] for its sound sever. I don't know if Pulse Audio already provides this capability, so depending upon whether the switch is made, this spec might be solved by the switch alone.

I'm uncertain whether common audio hardware can switch the sample rate midstream without creating any audible gap, so use case (2) might not be feasible (or at least not the best approach in all cases).

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

  • Launchpad entry: none yet

  • Packages affected:

Summary

Currently esound runs at a fixed sample rate (44100 samples per second). For both quality and performance reasons, esound (or whatever other sound server Ubuntu might migrate to) should dynamically negotiate the sample rate based on the rates of the active clients and the actual capabilities of the audio hardware.

Rationale

Esound runs at a fixed sample rate of 44100. However, audio hardware that supports at least up to 48000 is extremely common, and at least one common desktop use case is natively at 48000, DVD playback. In this case, the application (say Totem) must downsample the from 48000 to 44100. Downsampling is fairly computationally intensive and causes quality loss. This extra CPU time raising the minimum computing power required to play a DVD without dropping any frames, and causes quicker battery drain on portables.

High definition audio is starting to become more common. A desktop user should not be required to choose between utilizing a sample rate higher than 44100 and having software mixing available. A sound server that can provide dynamic sample rates is also a must for professional audio applications if they are to coexist with other desktop sound events (e.g., Gaim).

Use cases

  1. No client connected, new client connects: rate = min(client_rate, max_hardware_rate)
  2. At least one active client, new client connects or existing client disconnects: rate = min(max(client_rates), max_hardware_rate)

Scope

Design

I understand that Ubuntu is considering switching to [http://pulseaudio.org/ Pulse Audio] for its sound sever. I don't know if Pulse Audio already provides this capability, so depending upon whether the switch is made, this spec might be solved by the switch alone.

I'm uncertain whether common audio hardware can switch the sample rate midstream without creating any audible gap, so use case (2) might not be feasible (or at least not the best approach in all cases).

Implementation

Code

Data preservation and migration

Unresolved issues

BoF agenda and discussion


CategorySpec

DynamicAudioRateSpec (last edited 2008-08-06 16:26:41 by localhost)