new pcm format(s)

new pcm format(s)

[Guilhem Tardy]

Hi,

I have enquired last Friday about the preferred way for adding formats, since
I'd prefer not follow one option and have someone differ later on. Since I
received no answer, I guess no one as an opinion on the topic and there won't
be any argument. ;)

Anyway, I found out that there's not so much space left for more formats.
Therefore, I added one for G726 and started adding subformats (a field that was
unused until now). This also means that I need to update the function
snd_pcm_format_width() in order to deal with subformats.

Regards,
Guilhem.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: new pcm format(s)

[Takashi Iwai]

At Wed, 21 Aug 2002 13:47:40 -0700 (PDT),
Guilhem Tardy wrote:
> 
> Hi,
> 
> I have enquired last Friday about the preferred way for adding formats, since
> I'd prefer not follow one option and have someone differ later on.

i didn't see your post..  where did you post it?

> Since I received no answer, I guess no one as an opinion on the
> topic and there won't be any argument. ;)
> 
> Anyway, I found out that there's not so much space left for more formats.

the space must be enough.  at the last change of hw_params struct, we
extended the space for the sample format.


> Therefore, I added one for G726 and started adding subformats (a field that was
> unused until now). This also means that I need to update the function
> snd_pcm_format_width() in order to deal with subformats.

yes.
if you finished, please send the patch.
the patch is always welcome.


ciao,

Takashi



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: new pcm format(s)

[Guilhem Tardy]

> > Anyway, I found out that there's not so much space left for more formats.
> 
> the space must be enough.  at the last change of hw_params struct, we
> extended the space for the sample format.

Indeed, I managed to build RC3 at last (I'll port all my stuff to RC3 over the
WE) and found out that the SNDRV_PCM_FMTBIT_ are now defined as 64-bit unsigned
integers. But I think it would be worthwhile in the long run to use subformats.

> > Therefore, I added one for G726 and started adding subformats (a field that
> > was unused until now). This also means that I need to update the function
> > snd_pcm_format_width() in order to deal with subformats.
> 
> yes.
> if you finished, please send the patch.
> the patch is always welcome.

I built the ALSA framework (RC2) with those changes, but then all drivers must
be updated (e.g. dummy.c at line 207) to call snd_pcm_format_width() with 2
parameters: the format AND the subformat. Is this something you think would be
possible?

Guilhem.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: new pcm format(s)

[Takashi Iwai]

At Thu, 22 Aug 2002 07:37:42 -0700 (PDT),
Guilhem Tardy wrote:
> 
> > > Anyway, I found out that there's not so much space left for more formats.
> > 
> > the space must be enough.  at the last change of hw_params struct, we
> > extended the space for the sample format.
> 
> Indeed, I managed to build RC3 at last (I'll port all my stuff to RC3 over the
> WE) and found out that the SNDRV_PCM_FMTBIT_ are now defined as 64-bit unsigned
> integers. But I think it would be worthwhile in the long run to use subformats.

it's only on the kernel side for ease of use.
the api itself allows up to 256 (or more) formats.
so we can change it at any time.

> 
> > > Therefore, I added one for G726 and started adding subformats (a field that
> > > was unused until now). This also means that I need to update the function
> > > snd_pcm_format_width() in order to deal with subformats.
> > 
> > yes.
> > if you finished, please send the patch.
> > the patch is always welcome.
> 
> I built the ALSA framework (RC2) with those changes, but then all drivers must
> be updated (e.g. dummy.c at line 207) to call snd_pcm_format_width() with 2
> parameters: the format AND the subformat. Is this something you think would be
> possible?

is it needed to be a subformat?

also, note that runtime->format is not a mask but a value.
hence you can combine the format and subformat in each 16bit if
necessary.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: new pcm format(s)

[Guilhem Tardy]

> > the SNDRV_PCM_FMTBIT_ are now defined as 64-bit unsigned integers.
> > But I think it would be worthwhile in the long run to use subformats.
> 
> it's only on the kernel side for ease of use.
> the api itself allows up to 256 (or more) formats.
> so we can change it at any time.

Agreed. Then it is mostly a matter of choosing the right use for subformats
(currently: none).

> > I built the ALSA framework (RC2) with those changes, but then all drivers
> > must be updated (e.g. dummy.c at line 207) to call snd_pcm_format_width()
> > with 2 parameters: the format AND the subformat. Is this something you
> > think would be possible?
> 
> is it needed to be a subformat?

With RC3, no. The SNDRV_PCM_FMTBIT_ enums being defined as 64-bit unsigned
values, I can add the 4 variants of G726 and possibly move up the
SNDRV_PCM_FORMAT_SPECIAL a bit higher. BTW, which version of GSM does ALSA
support (there are several variants, too)?

> also, note that runtime->format is not a mask but a value.
> hence you can combine the format and subformat in each 16bit if
> necessary.

Yes, this is the way it was done until now (in the driver and library). But
then again, it is a choice. So what is the purpose of the subformat in your
view, and how do you want me to proceed further (as I am obviously inclined in
having this contributed back to the ALSA framework)?

Guilhem.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390