format specification problem

format specification problem

[Paul Davis]

 [ those of you on jack-dev will have seen this coming ]

ALSA doesn't seem to provide a way for a driver to way "i provide
samples in the native format of the processor". The specific case in
point that I'm noticing is the Hammerfall, where we currently say that
it supports S32_LE. This is not strictly true. It supports S32_LE when
it has the x86-friendly EPROM, and S32_BE when it has the ppc-friendly
EPROM. But it can't support them both at the same time. Moreover,
there isn't any way to find out which EPROM it has - its assumed that
the user is sufficiently smart not to have installed a PPC version on
an x86 system (I actually had a user recently who had this problem and
didn't realize it - they spent days trying to figure why their samples
were byte-swapped).

If an application wants to ask for S32 in "native" format, it can do
that, but <alsa/asoundlib.h> will convert that into either S32_LE or
S32_BE, and when we get down the driver level, it will fail on some
systems. 

How can we address this? I doubt that the Hammerfall is the only card
with this problem ...

--p

Re: format specification problem

[Abramo Bagnara]

Paul Davis wrote:
> 
>  [ those of you on jack-dev will have seen this coming ]
> 
> ALSA doesn't seem to provide a way for a driver to way "i provide
> samples in the native format of the processor". The specific case in
> point that I'm noticing is the Hammerfall, where we currently say that
> it supports S32_LE. This is not strictly true. It supports S32_LE when
> it has the x86-friendly EPROM, and S32_BE when it has the ppc-friendly
> EPROM. But it can't support them both at the same time. Moreover,
> there isn't any way to find out which EPROM it has - its assumed that
> the user is sufficiently smart not to have installed a PPC version on
> an x86 system (I actually had a user recently who had this problem and
> didn't realize it - they spent days trying to figure why their samples
> were byte-swapped).
> 
> If an application wants to ask for S32 in "native" format, it can do
> that, but <alsa/asoundlib.h> will convert that into either S32_LE or
> S32_BE, and when we get down the driver level, it will fail on some
> systems.
> 
> How can we address this? I doubt that the Hammerfall is the only card
> with this problem ...
> 

Actually they're two different cards, so they need to be treated as
such. I think that a module option is a suitable solution.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: format specification problem

[Takashi Iwai]

At Wed, 24 Apr 2002 20:55:56 -0400,
Paul Davis wrote:
> 
> 
>  [ those of you on jack-dev will have seen this coming ]
> 
> ALSA doesn't seem to provide a way for a driver to way "i provide
> samples in the native format of the processor". The specific case in
> point that I'm noticing is the Hammerfall, where we currently say that
> it supports S32_LE. This is not strictly true. It supports S32_LE when
> it has the x86-friendly EPROM, and S32_BE when it has the ppc-friendly
> EPROM. But it can't support them both at the same time. Moreover,
> there isn't any way to find out which EPROM it has - its assumed that
> the user is sufficiently smart not to have installed a PPC version on
> an x86 system (I actually had a user recently who had this problem and
> didn't realize it - they spent days trying to figure why their samples
> were byte-swapped).
>  
> If an application wants to ask for S32 in "native" format, it can do
> that, but <alsa/asoundlib.h> will convert that into either S32_LE or
> S32_BE, and when we get down the driver level, it will fail on some
> systems. 

simply use SNDRV_PCM_FORMAT_S32 (without _LE/_BE suffix) ?
then the byte-order is determined at the compile time.

but i vote for Abramo's proposal, since the mismatching may happen as
you wrote.  it should be configurable via module option or something
like that.


Takashi