more sample formats? too little place left.

more sample formats? too little place left.

[Takashi Iwai]

Hi,

it seems that USB audio supports 24 bit sample in 3 bytes format.
and additionally i've found there are 20bit and 18bit sample formats.
the world is large...

an arising problem is that the number of formats is limited to 32.
already 26 format types are used.  the rest are only 6, and not enough
if we put BE/LE and signed/unsigned for new formats, too.

how can we solve this?  extend to 64bit?  no, it has too overhead.
add a new field for special formats?

perhaps we don't need all of them for such special formats.
there are no unsigned types for such formats.
but anyway the left resource is too small.


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Martijn Sipkema]

> it seems that USB audio supports 24 bit sample in 3 bytes format.
> and additionally i've found there are 20bit and 18bit sample formats.
> the world is large...
> 
> an arising problem is that the number of formats is limited to 32.
> already 26 format types are used.  the rest are only 6, and not enough
> if we put BE/LE and signed/unsigned for new formats, too.
> 
> how can we solve this?  extend to 64bit?  no, it has too overhead.
> add a new field for special formats?
> 
> perhaps we don't need all of them for such special formats.
> there are no unsigned types for such formats.
> but anyway the left resource is too small.

are formats currently a bit in a 'supported formats' flag?

--martijn



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Martijn Sipkema]

> are formats currently a bit in a 'supported formats' flag?

i meant mask instead of flag...


--martijn



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Ville Syrjälä]

On Fri, May 31, 2002 at 04:23:23PM +0200, Takashi Iwai wrote:
> Hi,
> 
> it seems that USB audio supports 24 bit sample in 3 bytes format.
> and additionally i've found there are 20bit and 18bit sample formats.
> the world is large...
> 
> an arising problem is that the number of formats is limited to 32.
> already 26 format types are used.  the rest are only 6, and not enough
> if we put BE/LE and signed/unsigned for new formats, too.
> 
> how can we solve this?  extend to 64bit?  no, it has too overhead.
> add a new field for special formats?

What do you mean by overhead? Binary compatibility maybe?

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Takashi Iwai]

At Fri, 31 May 2002 19:36:54 +0100,
Martijn Sipkema wrote:
> 
> > it seems that USB audio supports 24 bit sample in 3 bytes format.
> > and additionally i've found there are 20bit and 18bit sample formats.
> > the world is large...
> > 
> > an arising problem is that the number of formats is limited to 32.
> > already 26 format types are used.  the rest are only 6, and not enough
> > if we put BE/LE and signed/unsigned for new formats, too.
> > 
> > how can we solve this?  extend to 64bit?  no, it has too overhead.
> > add a new field for special formats?
> > 
> > perhaps we don't need all of them for such special formats.
> > there are no unsigned types for such formats.
> > but anyway the left resource is too small.
> 
> are formats currently a bit in a 'supported formats' flag?

yes.

the problem is that the bitmask is defined as unsigned int, und
limitied to 31 bits.

if it's only in alsa driver, then it wouldn't be serious.
but apparently alsa-lib defines also mask as an integer.
theoretically, redefining this type won't cause any compatibility
problems, though, as long as you link alsa-lib dynamically.
(it's an obvious advantage of "complicated" alsa api :)


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Takashi Iwai]

At Sun, 2 Jun 2002 03:22:00 +0300,
Ville Syrjälä wrote:
> 
> On Fri, May 31, 2002 at 04:23:23PM +0200, Takashi Iwai wrote:
> > Hi,
> > 
> > it seems that USB audio supports 24 bit sample in 3 bytes format.
> > and additionally i've found there are 20bit and 18bit sample formats.
> > the world is large...
> > 
> > an arising problem is that the number of formats is limited to 32.
> > already 26 format types are used.  the rest are only 6, and not enough
> > if we put BE/LE and signed/unsigned for new formats, too.
> > 
> > how can we solve this?  extend to 64bit?  no, it has too overhead.
> > add a new field for special formats?
> 
> What do you mean by overhead? Binary compatibility maybe?

perhaps not too much overhead as i thought.
binary compatibility might be a problem, although alsa-lib can hide
the change of its own structs.

but the question is whether we should just add such new formats as new
bits, or define something more ordinary.


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Martijn Sipkema]

> > > it seems that USB audio supports 24 bit sample in 3 bytes format.
> > > and additionally i've found there are 20bit and 18bit sample formats.
> > > the world is large...
> > >
> > > an arising problem is that the number of formats is limited to 32.
> > > already 26 format types are used.  the rest are only 6, and not enough
> > > if we put BE/LE and signed/unsigned for new formats, too.
> > >
> > > how can we solve this?  extend to 64bit?  no, it has too overhead.
> > > add a new field for special formats?
> > >
> > > perhaps we don't need all of them for such special formats.
> > > there are no unsigned types for such formats.
> > > but anyway the left resource is too small.
> >
> > are formats currently a bit in a 'supported formats' flag?
>
> yes.
>
> the problem is that the bitmask is defined as unsigned int, und
> limitied to 31 bits.
>
> if it's only in alsa driver, then it wouldn't be serious.
> but apparently alsa-lib defines also mask as an integer.
> theoretically, redefining this type won't cause any compatibility
> problems, though, as long as you link alsa-lib dynamically.
> (it's an obvious advantage of "complicated" alsa api :)

perhaps not using a bitmask, but having two ioctls, one giving
the number of supported formats, the other returning the format
description taking an index argument, not unlike the EASI interface
, might be better.

--martijn




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Frank van de Pol]

Using the mask is only usefull for inquiry of supported formats; if it was
for specifying a format a simple numeric value would be fine. 

Would extending the bitfield to 64 bits solve the problem for now and
forever? I suppose it would give us some air, but on the other hand, more
formats exist in the world, with each different packing and notiation. 

eg. 18 and 20 bits packed in 24 bits or 32 bits stream; floating point
formats in various flavours like 32 bit 24.0, 32 bit 16.8, 32 bit 0.24 etc.
- ok, last one is supported as SND_PCM_FORMAT_FLOAT_LE/BE). Not to mention
future things like the GSM/MPEG/ADPCM encodings etc. 

just thinking out loud... 

Frank.

On Mon, Jun 03, 2002 at 03:43:56PM +0200, Takashi Iwai wrote:
> At Fri, 31 May 2002 19:36:54 +0100,
> Martijn Sipkema wrote:
> > 
> > > it seems that USB audio supports 24 bit sample in 3 bytes format.
> > > and additionally i've found there are 20bit and 18bit sample formats.
> > > the world is large...
> > > 
> > > an arising problem is that the number of formats is limited to 32.
> > > already 26 format types are used.  the rest are only 6, and not enough
> > > if we put BE/LE and signed/unsigned for new formats, too.
> > > 
> > > how can we solve this?  extend to 64bit?  no, it has too overhead.
> > > add a new field for special formats?
> > > 
> > > perhaps we don't need all of them for such special formats.
> > > there are no unsigned types for such formats.
> > > but anyway the left resource is too small.
> > 
> > are formats currently a bit in a 'supported formats' flag?
> 
> yes.
> 
> the problem is that the bitmask is defined as unsigned int, und
> limitied to 31 bits.
> 

-- 
+---- --- -- -  -   -    - 
| Frank van de Pol                  -o)    A-L-S-A
| FvdPol@home.nl                    /\\  Sounds good!
| http://www.alsa-project.org      _\_v
| Linux - Why use Windows if we have doors available?

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Dan Hollis]

On Mon, 3 Jun 2002, Takashi Iwai wrote:
> but the question is whether we should just add such new formats as new
> bits, or define something more ordinary.

A format descriptor structure, instead of hardcoded format types?

Of course you will want a good API support structure for handling format 
conversions...

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Takashi Iwai]

At Mon, 3 Jun 2002 14:32:43 -0700 (PDT),
Dan Hollis wrote:
> 
> On Mon, 3 Jun 2002, Takashi Iwai wrote:
> > but the question is whether we should just add such new formats as new
> > bits, or define something more ordinary.
> 
> A format descriptor structure, instead of hardcoded format types?
> 
> Of course you will want a good API support structure for handling format 
> conversions...

hmm, i don't think it must be a struct.  enum (int) could have enough
values if it's not bitmask, although the order of format enumerators
may look a bit weird.  there are already functions to retrieve a
detail information from the format type enum, such as
snd_pcm_format_width() and snd_pcm_format_little_endian().

so far, the bitmask is used only inside the alsa-driver and alsa-lib.
they must be extended in some good way.  i believe that this change
can be hidden without changing API itself, but not figure out how
should we do that yet.


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Dan Hollis]

On Tue, 4 Jun 2002, Takashi Iwai wrote:
> > Of course you will want a good API support structure for handling format 
> > conversions...
> hmm, i don't think it must be a struct.  enum (int) could have enough
> values if it's not bitmask, although the order of format enumerators
> may look a bit weird.  there are already functions to retrieve a
> detail information from the format type enum, such as
> snd_pcm_format_width() and snd_pcm_format_little_endian().

we want something expandable but avoid ugliness. something that jaroslav 
has been very good at so far (with switches, etc)

65535 different formats should be enough :-) and if there are functions to 
provide detailed descriptions of the formats, i think it's a good 
solution. even if the order of the formats looks strange because more are 
added on later.

> so far, the bitmask is used only inside the alsa-driver and alsa-lib.
> they must be extended in some good way.  i believe that this change
> can be hidden without changing API itself, but not figure out how
> should we do that yet.

and do it right the first time :-)

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: more sample formats? too little place left.

[Takashi Iwai]

At Tue, 4 Jun 2002 13:55:54 -0700 (PDT),
Dan Hollis wrote:
> 
> On Tue, 4 Jun 2002, Takashi Iwai wrote:
> > > Of course you will want a good API support structure for handling format 
> > > conversions...
> > hmm, i don't think it must be a struct.  enum (int) could have enough
> > values if it's not bitmask, although the order of format enumerators
> > may look a bit weird.  there are already functions to retrieve a
> > detail information from the format type enum, such as
> > snd_pcm_format_width() and snd_pcm_format_little_endian().
> 
> we want something expandable but avoid ugliness. something that jaroslav 
> has been very good at so far (with switches, etc)
> 
> 65535 different formats should be enough :-) and if there are functions to 
> provide detailed descriptions of the formats, i think it's a good 
> solution. even if the order of the formats looks strange because more are 
> added on later.
> 
> > so far, the bitmask is used only inside the alsa-driver and alsa-lib.
> > they must be extended in some good way.  i believe that this change
> > can be hidden without changing API itself, but not figure out how
> > should we do that yet.
> 
> and do it right the first time :-)

i talked (yes, physically!) with Jaroslav about this issue.
our conclusion is to extend the snd_pcm_hw_constraints_t struct,
namely, using char arrays instead of int for mask bits.
this will require an update of alsa-lib, too.  the old alsa-lib
won't run.  but applications are not necessarily compiled.
the other things should be kept as they were.
the order is ugly, but they are mostly exceptional cases.
we don't want to break compatibility on this stage.

i think this change can slip into rc2 (hopefully).


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

Re: more sample formats? too little place left.

[Dan Hollis]

On Mon, 10 Jun 2002, Takashi Iwai wrote:
> i talked (yes, physically!) with Jaroslav about this issue.
> our conclusion is to extend the snd_pcm_hw_constraints_t struct,
> namely, using char arrays instead of int for mask bits.

you mean represent each mask bit with separate ascii character?

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

Re: more sample formats? too little place left.

[Takashi Iwai]

At Mon, 10 Jun 2002 13:46:04 -0700 (PDT),
Dan Hollis wrote:
> 
> On Mon, 10 Jun 2002, Takashi Iwai wrote:
> > i talked (yes, physically!) with Jaroslav about this issue.
> > our conclusion is to extend the snd_pcm_hw_constraints_t struct,
> > namely, using char arrays instead of int for mask bits.
> 
> you mean represent each mask bit with separate ascii character?

no, it's just a byte array as bitmap to hold more than 32bit (int).
the meaning is same, but the size will be bigger.


Takashi

_______________________________________________________________

Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/

Re: more sample formats? too little place left.

[Dan Hollis]

On Wed, 12 Jun 2002, Takashi Iwai wrote:
> At Mon, 10 Jun 2002 13:46:04 -0700 (PDT),
> Dan Hollis wrote:
> > you mean represent each mask bit with separate ascii character?
> no, it's just a byte array as bitmap to hold more than 32bit (int).
> the meaning is same, but the size will be bigger.

It will be fixed size char array? Or it will be variable?

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]


_______________________________________________________________

Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/