headers
Ross Bencina | 1 May 2008 10:11
Favicon

Re: Padding 24-bit samples

Hi Richard

It's difficult to offer suggestions for other approaches without 
understanding why you want/need to use the padded 24 bit format in the first 
place.

I can only guess that you're using an fixed-point integer decoder which 
outputs samples in this format.

I imagine a loop that shifts all the samples left by 8 bits will not cost 
much.. but I understand your concern to make things as optimised as 
possible.. and agree this might be work which can be avoided.

Keep in mind that you may not avoid  conversion overhead if lower levels of 
the system then have to reconvert the samples to another format anyway. Are 
you sure that the format of all intermediate buffering and bus-transfers 
occur as padded 24-bit with the same endianess as the host?

In principal I don't see a problem with accepting such a patch, however it 
would need to accomodate all of the conversion functions to other PA sample 
types, and all relevant clipping/dithering variants -- since we already have 
a bit of a release blocker with the few (obscure) unimplemented conversion 
functions for currently "supported" formats.

Best wishes

Ross.

----- Original Message ----- 
From: "Richard Titmuss" <richard_titmuss <at> logitech.com>
(Continue reading)

Permalink | Reply |
headers
Richard Titmuss | 2 May 2008 23:28
Favicon

Re: Padding 24-bit samples

Ross Bencina wrote:
> It's difficult to offer suggestions for other approaches without 
> understanding why you want/need to use the padded 24 bit format in the 
> first place.
>
> I can only guess that you're using an fixed-point integer decoder 
> which outputs samples in this format.
Yes, the decoders used do output in this format. On the embedded 
platforms I am designing for the DACs are also 24 bit, and the samples 
need to be buffered in this format.

> Keep in mind that you may not avoid  conversion overhead if lower 
> levels of the system then have to reconvert the samples to another 
> format anyway. Are you sure that the format of all intermediate 
> buffering and bus-transfers occur as padded 24-bit with the same 
> endianess as the host?
I am fairly sure, but I will double check this before starting to add 
padded 24-bit samples for portaudio. I know alsa can directly support 
this format, do you know if any of the other hostapi's can too?

> In principal I don't see a problem with accepting such a patch, 
> however it would need to accomodate all of the conversion functions to 
> other PA sample types, and all relevant clipping/dithering variants -- 
> since we already have a bit of a release blocker with the few 
> (obscure) unimplemented conversion functions for currently "supported" 
> formats.
If I decide to continue then I'll have an initial patch (without all the 
conversion functions) for review sometime next week. Given that's ok 
I'll look at adding support for the other conversion functions.
(Continue reading)

Permalink | Reply |
headers
Ross Bencina | 5 May 2008 10:11
Favicon

Re: Padding 24-bit samples + V19 dither bug

Hi Richard

>I am fairly sure, but I will double check this before starting to add
>padded 24-bit samples for portaudio. I know alsa can directly support
>this format, do you know if any of the other hostapi's can too?

ASIO defines 32 bit sample types with padding for 16, 18, 20 and 24 bit in 
both endiannesses. pa_asio.c runs a separate loop to byteswap and align 
these samples to paInt32 format. But to say that ASIO "supports" these 
formats is not quite right since ASIO will always use the one format the 
driver requests --the client is always required to provide data in the 
format that ASIO requests.

> I have been doing some experiments today, and have been using the
> PaInt32 to PaInt16 dither function. This does not seem to work
> correctly. Attached is a modified version of patest_sine.c that uses the
> PaInt32 sample type. When played in 16-bits, using dithering for the
> conversion then the maximum and minimum samples are distorted. This is
> clearly seen by recording and viewing the output.
>
> The attached patch fixes this by applying clipping before casting to
> PaInt16. The comments in pa_converters.c suggest that maybe all
> functions that dither should include clipping, is there a reason why
> they don't? The patch also shifts the dither to use only 15 bits, the
> existing code modifies the least-significant bit of the sample and I
> don't think this is correct.

Thanks, I will try to look at this further soon but if anyone else is able 
to review it / comment on it that would be great. I think I mainly just 
tried to duplicate Phil's dithering code from V18...
(Continue reading)

Permalink | Reply |

Gmane