new "in-compatible" alsa-lib PCM API

new "in-compatible" alsa-lib PCM API

[Jaroslav Kysela]

Hi all,

	I've made a simple cleanup which unifies all snd_pcm_hw_params_* 
functions. The first set of changes are in CVS a few days, but some 
developers pointed that the backwards compatibility is a right thing.
	After some thoughs, I think that this sort of cleanups is good for 
implementing at any time. It doesn't break the implementation (in the 
sense of behaviour), but it makes that older code is not compilable. 
Fortunately, any C programmer can fix the compilation in this case, so 
it's definitely not a big problem.
	The much bigger drawback is that we have no binary compatibility 
with older applications. I decided to use the versioned symbols in the 
future versions of alsa library and to keep the binary compatibility with 
older versions of library (function declarations). At the time, we have 
two symbol versions: ALSA_0.9.0 and ALSA_0.9.0rc4.
	These solutions exists for co-existing older and newer 
applications:

1) New "versioned" library is libasound.so.3, so that older applications 
   uses older libasound.so.2. 
2) Recompile older applications with "compatible library" which contains
   versioned symbols ALSA_0.9, but headers are compatible with 0.9.0rc3. 
   This library will be also libasound.so.3, but ALL symbols have ALSA_0.9 
   tag which allows to override functions in future. The compatible library
   will be built when '--with-compat-rc3' argument is passed to the 
   configure script in alsa-lib. This solution allows keeping binary 
   compatibility and allows to update alsa-lib with recent one (built 
   without --with-compat-rc3).

I suggest to use the second solution from this time.

Objections/further discussion is welcome.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Kai Vehmanen]

On Tue, 17 Sep 2002, Jaroslav Kysela wrote:

> 1) New "versioned" library is libasound.so.3, so that older applications 
>    uses older libasound.so.2. 

Hmm, the 'Versions' ld script doesn't seem to be in CVS, and as a result,
linking alsa-lib currently fails. Have I missed something?
 
-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Jaroslav Kysela]

On Tue, 17 Sep 2002, Kai Vehmanen wrote:

> On Tue, 17 Sep 2002, Jaroslav Kysela wrote:
> 
> > 1) New "versioned" library is libasound.so.3, so that older applications 
> >    uses older libasound.so.2. 
> 
> Hmm, the 'Versions' ld script doesn't seem to be in CVS, and as a result,
> linking alsa-lib currently fails. Have I missed something?

Oops. Sorry. Fixed now.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Jack O'Quin]

Is this a "Release-Critical" bug fix?  

If not, I think source- and binary-incompatible changes are highly
inappropriate right now.  A "release candidate" is supposed to
*stabilize* the interface and implementation.  Making an incompatible
change between rc3 and rc4 looks like a big step backwards.

If at all possible, let's postpone this cleanup until after ALSA 0.9.0
is released.  Put the release in maintenance mode, then clean up these
functions in the 1.0.0 development tree.  That will also be a good
time to increment the library version number.

Jaroslav Kysela <perex@perex.cz> writes:

> 	I've made a simple cleanup which unifies all snd_pcm_hw_params_* 
> functions. The first set of changes are in CVS a few days, but some 
> developers pointed that the backwards compatibility is a right thing.
> 	After some thoughs, I think that this sort of cleanups is good for 
> implementing at any time. It doesn't break the implementation (in the 
> sense of behaviour), but it makes that older code is not compilable. 
> Fortunately, any C programmer can fix the compilation in this case, so 
> it's definitely not a big problem.
> 	The much bigger drawback is that we have no binary compatibility 
> with older applications. I decided to use the versioned symbols in the 
> future versions of alsa library and to keep the binary compatibility with 
> older versions of library (function declarations). At the time, we have 
> two symbol versions: ALSA_0.9.0 and ALSA_0.9.0rc4.
> 	These solutions exists for co-existing older and newer 
> applications:
> 
> 1) New "versioned" library is libasound.so.3, so that older applications 
>    uses older libasound.so.2. 
> 2) Recompile older applications with "compatible library" which contains
>    versioned symbols ALSA_0.9, but headers are compatible with 0.9.0rc3. 
>    This library will be also libasound.so.3, but ALL symbols have ALSA_0.9 
>    tag which allows to override functions in future. The compatible library
>    will be built when '--with-compat-rc3' argument is passed to the 
>    configure script in alsa-lib. This solution allows keeping binary 
>    compatibility and allows to update alsa-lib with recent one (built 
>    without --with-compat-rc3).
> 
> I suggest to use the second solution from this time.
> 
> Objections/further discussion is welcome.

Regards,
-- 
  Jack O'Quin
  Austin, Texas, USA
  http://www.stellajazz.com


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Jaroslav Kysela]

On 17 Sep 2002, Jack O'Quin wrote:

> Is this a "Release-Critical" bug fix?  
> 
> If not, I think source- and binary-incompatible changes are highly
> inappropriate right now.  A "release candidate" is supposed to
> *stabilize* the interface and implementation.  Making an incompatible
> change between rc3 and rc4 looks like a big step backwards.
> 
> If at all possible, let's postpone this cleanup until after ALSA 0.9.0
> is released.  Put the release in maintenance mode, then clean up these
> functions in the 1.0.0 development tree.  That will also be a good
> time to increment the library version number.

You're right, if we don't provide the possibility to build a compatible 
library. If you don't like our changes, simply configure your library with 
--with-compat-rc3 and your - not yet updated - applications will be happy.
Note that these binaries will use newer (0.9.0rc4) library without any 
problems so the co-existence between older and newer applications is 
assured. The binary compatibility is really important thing for us, so I 
spend a few of days to create this compatibility layer.

I really regret to make this sort of modifications at the time, but:

- any later modifications will cause more changes for applications 
  developers (the amount software around alsa-lib grows)
- the symbol versioning is really a good thing; the fact that the basic
  glibc 2.0 is build with this method is a good approved example to keep
  the binary compatibility with all applications build on top of this 
  library, look for implementation of some functions there, the syntax 
  slightly changed for many of them

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Takashi Iwai]

At Tue, 17 Sep 2002 14:58:42 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> Hi all,
> 
> 	I've made a simple cleanup which unifies all snd_pcm_hw_params_* 
> functions. The first set of changes are in CVS a few days, but some 
> developers pointed that the backwards compatibility is a right thing.
> 	After some thoughs, I think that this sort of cleanups is good for 
> implementing at any time. It doesn't break the implementation (in the 
> sense of behaviour), but it makes that older code is not compilable. 
> Fortunately, any C programmer can fix the compilation in this case, so 
> it's definitely not a big problem.
> 	The much bigger drawback is that we have no binary compatibility 
> with older applications. I decided to use the versioned symbols in the 
> future versions of alsa library and to keep the binary compatibility with 
> older versions of library (function declarations). At the time, we have 
> two symbol versions: ALSA_0.9.0 and ALSA_0.9.0rc4.
> 	These solutions exists for co-existing older and newer 
> applications:
> 
> 1) New "versioned" library is libasound.so.3, so that older applications 
>    uses older libasound.so.2. 
> 2) Recompile older applications with "compatible library" which contains
>    versioned symbols ALSA_0.9, but headers are compatible with 0.9.0rc3. 
>    This library will be also libasound.so.3, but ALL symbols have ALSA_0.9 
>    tag which allows to override functions in future. The compatible library
>    will be built when '--with-compat-rc3' argument is passed to the 
>    configure script in alsa-lib. This solution allows keeping binary 
>    compatibility and allows to update alsa-lib with recent one (built 
>    without --with-compat-rc3).
> 
> I suggest to use the second solution from this time.

using the versioned symbols is a good idea.  it should go into
libasound.so.3 to avoid the further confliction.

but i still wonder whether it's possible not to modify the existing
api functions but to add new functions instead.
modifying the existing function means not only that the library
binares conflict but also that the application code must be changed,
too.  perhaps applications need to check the library version and bunch
of ifdef's or hacks, because many distribution includes still the old
alsa lib.

if we want to _force_ users to follow all the changes (e.g. the
function is really buggy, etc), then we should change the existing
function.
but in other cases - if the old api functions still work somehow -
adding new api functions makes our life happier.
we can put notes in the doc that the functions are obsolete.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Richard Bown]

On Wednesday 18 September 2002 10:36, Takashi Iwai wrote:

> using the versioned symbols is a good idea.  it should go into
> libasound.so.3 to avoid the further confliction.

I don't know about anyone else but I'm really confused.

All I know is that JACK CVS doesn't build out of the box with ALSA CVS now
and that to me says "painful".  But hey, I'm an app developer and I'm allowed
to whinge.  Right?

Wake me up when it's all over.

B


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Takashi Iwai]

At Wed, 18 Sep 2002 10:46:42 +0100,
Richard Bown wrote:
> 
> On Wednesday 18 September 2002 10:36, Takashi Iwai wrote:
> 
> > using the versioned symbols is a good idea.  it should go into
> > libasound.so.3 to avoid the further confliction.
> 
> I don't know about anyone else but I'm really confused.
> 
> All I know is that JACK CVS doesn't build out of the box with ALSA CVS now
> and that to me says "painful".  But hey, I'm an app developer and I'm allowed
> to whinge.  Right?

yes, you can, but it'd be better to say what you prefer to.

we're trying to keep the compatibility from the old versions.  it's
exactly what you want.
Jaroslav showed the double interface with different version numbering,
and I suggested to add new functions instead of replacement.

> Wake me up when it's all over.

please give comments before going to bed.
(otherwise you will lose the right to whinge ;)
the decision should not be done self-righteously.


ciao,

Takashi


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Richard Bown]

On Wednesday 18 September 2002 11:06, Takashi Iwai wrote:
> > Wake me up when it's all over.
>
> please give comments before going to bed.
> (otherwise you will lose the right to whinge ;)
> the decision should not be done self-righteously.

I know that you and Jaroslav will come to a fair an equitable decision without me
muddying the waters..

..however, after thinking about it (and since you asked) I think it makes more sense to
do what you're suggesting and keep the old API in addition to the new one and just mark
the old one as deprecated for the next release or three.  Then you can phase out the old
interface in (say) six months time or something.  The thing shouldn't just break though
and I agree with what you're saying about #ifdefs - there are enough of those about as
it stands without adding more to the pile.

Anyway, just my 2c.
 
And so to bed.

B


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Kai Vehmanen]

On Tue, 17 Sep 2002, Jaroslav Kysela wrote:

> 	After some thoughs, I think that this sort of cleanups is good for 
> implementing at any time. It doesn't break the implementation (in the 
> sense of behaviour), but it makes that older code is not compilable. 
> Fortunately, any C programmer can fix the compilation in this case, so 
> it's definitely not a big problem.

I understand this change needed to be done, but I'd still like to humbly
remind of the effects of breaking source-level compatibility, even if
the binary-level compatibility is preserved.

I'm currently maintaining nearly a dozen applications that use the ALSA
0.9 PCM API. These apps have hundreds of users that have the latest 0.9rc
or a CVS-snapshot installed. Now I'm facing a situation where I need to
patch all these apps with new and old code plus ifdefs, test, release new
versions and possibly inform users that "if you want to upgrade to 
0.9-rc4/CVS, you must also upgrade app X, or otherwise compiling X will 
fail".

In any case this will be bad PR for ALSA and generate a lot of work 
for developers working on ALSA and apps using ALSA. You wouldn't believe 
how much I still get mail from people who are...

- trying to compile 0.5.x only apps against 0.9.x
- trying to compile 0.9.x apps against 0.5.x
- have 0.9.x packages installed but a 0.5.x style modules.conf 
- have different versions of alsa-driver/alsa-lib/alsa-utils installed

... and most of time the problem report is as detailed as "ALSA is not
working on my machine". ;) And now I can add the "rc[1-3] vs rc[4-]" to
the list.

And I must say that there are quite a few people out there who have a
really negative attitude against ALSA, because of old API changes and/or
documentation issues. This, of course, is not the fault of ALSA
developers, but it's still something that affects all of us, who are
interested in a succesful future for ALSA.

Some random ideas for future:

- Python style interface changing, where old interfaces are first 
  deprecated for one major release (with clearly visible warnings), 
  and removed from the next major release [1]
- make the API changes between major releases
	-> less of an suprise for both users and developers

[1] You could for instance have a ALSA_USE_API_V1_1 (or some such)
    preprocessor definition that would select the new
    API (ie. apps would define ALSA_USE_API_V1_1 before including
    alsa/asoundlib.h). This would allow apps to start using 
    a new API between major releases, without causing any source
    nor binary level incompabilities.

PS In any case, thanks to Jaroslav for adding symbol
   versioning to alsa-lib. Things like this are also good
   from PR perspective... ;)

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Chris Rankin]

Does this mean that the alsa-lib needs to be updated in CVS to be -rc4? 
I am trying to compile xine and wine from CVS as well as ALSA, and this 
doesn't work because alsa-utils needs the new headers but xine and wine 
currently need the old ones. I imagine that the xine and wine people can 
update their code-bases accordingly, but I doubt that they would relish 
the prospect of checking for each changed ALSA API in their configure 
scripts.

Chris



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Jaroslav Kysela]

On Wed, 18 Sep 2002, Chris Rankin wrote:

> Does this mean that the alsa-lib needs to be updated in CVS to be -rc4? 
> I am trying to compile xine and wine from CVS as well as ALSA, and this 
> doesn't work because alsa-utils needs the new headers but xine and wine 
> currently need the old ones. I imagine that the xine and wine people can 
> update their code-bases accordingly, but I doubt that they would relish 
> the prospect of checking for each changed ALSA API in their configure 
> scripts.

The library version can be easy detected at compilation code. The SND_LIB_EXTRAVER
define is 100000 for 0.9.0rc3, 100003 for CVS version of alsa-lib and will 
be 100004 for 0.9.0rc4. Note: If SND_COMPATIBILITY_BUILD_RC3 is defined, 
then applications need to fall back to 0.9.0rc3 API as well.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Chris Rankin]

 --- Jaroslav Kysela <perex@perex.cz> wrote: > On Wed,
18 Sep 2002, Chris Rankin wrote:
> Note: If
> SND_COMPATIBILITY_BUILD_RC3 is defined, 
> then applications need to fall back to 0.9.0rc3 API
> as well.

So maybe we could have a --with-compat-rc3 option for
alsa-utils as well? Regardless of which alsa-lib I
build, I always need to be able to build alsa-utils.
And I doubt that wine and xine will get updated before
-rc4 is released. (Unless there's a document somewhere
explaining the relationship between the old and new
API functions, in which case I could submit patches
myself.)

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Jaroslav Kysela]

On Wed, 18 Sep 2002, [iso-8859-1] Chris Rankin wrote:

>  --- Jaroslav Kysela <perex@perex.cz> wrote: > On Wed,
> 18 Sep 2002, Chris Rankin wrote:
> > Note: If
> > SND_COMPATIBILITY_BUILD_RC3 is defined, 
> > then applications need to fall back to 0.9.0rc3 API
> > as well.
> 
> So maybe we could have a --with-compat-rc3 option for
> alsa-utils as well? Regardless of which alsa-lib I
> build, I always need to be able to build alsa-utils.
> And I doubt that wine and xine will get updated before
> -rc4 is released. (Unless there's a document somewhere
> explaining the relationship between the old and new
> API functions, in which case I could submit patches
> myself.)

It seems, that you're not understand the compatibility.

1) build library with --with-compat-rc3 and place it to some
   other directory
3) build library without --with-compat-rc3, place it to
   /usr/lib as usuall
4) build alsa-utils and newer applications
5) build older applications with compatible library compiled
   with --with-compat-rc3

Old and new software will co-exist without any problems. Perhaps, we
can have some good default place for rc3 compatible library and add an 
autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3 
directory for this job. Comments?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Tim Goetze]

Jaroslav Kysela wrote:

>autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3 
>directory for this job. Comments?

/opt is redhat only, debian systems do not have it.

tim



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Thierry Vignaud]

Tim Goetze <tim@quitte.de> writes:

> > autoconfiguration code to alsa.m4. My suggestion is to use
> > /opt/alsa/rc3 directory for this job. Comments?
>
> /opt is redhat only, debian systems do not have it.

err, even if i dislike it, /opt is defined by the fhs

anyway, api incompatibles libraries can cohabit in the same place with
different majors.

debian and major enable one to have multiples versions of the same lib
provided the upstream authors increase it major on each api and/or abi
change. one can only have one devel library package (aka headers, ...)

this is the /usr/share/aclocal/alsa.m4 job to provide right linking
flags depending of the library



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Paul Davis]

>this is the /usr/share/aclocal/alsa.m4 job to provide right linking
>flags depending of the library

ah. typical autoconf confusion here.

autoconf looks in only ONE directory by default for *.m4 files. if it
was installed from a package, it probably looks in
/usr/share/aclocal. if it was installed from source, it probably looks
in /usr/local/share/aclocal. there is no way to make it look in both
places without supplying explicit command line arguments, and since
autoconf is frequently run by the entire configure system, this is
hard to do. why autoconf does this is beyond me; it entirely forgets
the long unix tradition of FOO_PATH environment variables.

this causes no end of difficulties when using software that is
generally installed from a tgz or CVS (such as ALSA) on systems where
autoconf was installed from a package. autoconf will complain that it
can't find the foo.m4 file (because its in the "wrong" place). 

--p



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Takashi Iwai]

At Wed, 18 Sep 2002 10:19:48 -0400,
Paul Davis wrote:
> 
> this causes no end of difficulties when using software that is
> generally installed from a tgz or CVS (such as ALSA) on systems where
> autoconf was installed from a package. autoconf will complain that it
> can't find the foo.m4 file (because its in the "wrong" place). 

<off-topic>
ALSA uses /usr as the default prefix, so _usually_ the path is
identical with the system's.
</off-topic>


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Tim Goetze]

Thierry Vignaud wrote:

>Tim Goetze <tim@quitte.de> writes:
>
>> > autoconfiguration code to alsa.m4. My suggestion is to use
>> > /opt/alsa/rc3 directory for this job. Comments?
>>
>> /opt is redhat only, debian systems do not have it.
>
>err, even if i dislike it, /opt is defined by the fhs
>
>anyway, api incompatibles libraries can cohabit in the same place with
>different majors.
>
>debian and major enable one to have multiples versions of the same lib
>provided the upstream authors increase it major on each api and/or abi
>change. one can only have one devel library package (aka headers, ...)
>
>this is the /usr/share/aclocal/alsa.m4 job to provide right linking
>flags depending of the library

anyway, i agree with paul that pkg-config should be used instead,
which offers a lot more flexibility.

now that i think about it some more, i feel compelled to add:

this dance around the 0.9.0 version seems ridiculous to me. the
logical consequence of API changes is bumping the version number,
and not hiding it in a 'nano' version increment.

sorry for the harsh words,

tim




-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Richard Bown]

On Wednesday 18 September 2002 15:50, Tim Goetze wrote:

> anyway, i agree with paul that pkg-config should be used instead,
> which offers a lot more flexibility.

That's as maybe but it's "non-standard" still isn't it?  Another dependency
in a complicated world.  I think it's too soon.

However, all this scratching's making me bored.

B


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Paul Davis]

>> anyway, i agree with paul that pkg-config should be used instead,
>> which offers a lot more flexibility.
>
>That's as maybe but it's "non-standard" still isn't it?  Another dependency
>in a complicated world.  I think it's too soon.

its part of all distributions at this point. its about as standard as
autoconf. 

--p


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Richard Bown]

On Wednesday 18 September 2002 16:18, Paul Davis wrote:
> its part of all distributions at this point. its about as standard as
> autoconf.

While it may be part of the distros it's not always installed as default.
My SuSE 8.0 DVD has it on but I still had to fish it out.

While we're at it - did I dream that JACK CVS is now looking for fltk by
default configure or was that reality?

B


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Patrick Shirkey]

Tim Goetze wrote:

> now that i think about it some more, i feel compelled to add:
> 
> this dance around the 0.9.0 version seems ridiculous to me. the
> logical consequence of API changes is bumping the version number,
> and not hiding it in a 'nano' version increment.
> 
> sorry for the harsh words,
> 

So does that mean ALSA has reached 1.1.0?

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Paul Davis]

>1) build library with --with-compat-rc3 and place it to some
>   other directory
>3) build library without --with-compat-rc3, place it to
>   /usr/lib as usuall
>4) build alsa-utils and newer applications
>5) build older applications with compatible library compiled
>   with --with-compat-rc3
>
>Old and new software will co-exist without any problems. Perhaps, we
>can have some good default place for rc3 compatible library and add an 
>autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3 
>directory for this job. Comments?

the use of autoconf files like alsa.m4 is now deprecated by the very
people who invented them. can we please use pkgconfig instead? its
much more flexible.

i don't like the above scheme at all. 

what's going on here is the same thing that was happening a year ago,
only now *some* level of attention is being paid to the notion of
binary compatibility. the problem is, its not the right kind of
attention. the changes that have been made break the API. a year ago,
there was no problem telling us app developers that we just had to
keep following the API changes. now, because we are at 0.9.0rcN, there
is some sense that this isn't OK to do. the problem is that the
solution being provided as an alternative to "change your code" is
really rather cumbersome and awkward.

how should we carry out step (5) when we may not "know" where the rc3
library is to be found? this necessitates having alsa-rc3.m4 (or
better, alsa-rc3.pc) floating around, and STILL changing apps - just
their configure files, not their source. its worse, however, because a
lot of apps don't use alsa.m4 (i didn't even know it existed, for
example). they just use AC_CHECK_LIB, which will almost certainly look
in the place where the rc4 library is probably installed. its not easy
to make it do anything else.

look, once again the API has been modified without any attempt to
notify application developers ahead of time, without any attempt to
collect input from application developers and without any prior plan
for how to maintain back-compatability. this is very very regrettable.

but the changes have been made, they appear to be for a good reason,
and i think that its probably best to just forget about trying to
maintain back-compatibility in any way. the problem i see coming up is
that the attitude that these kinds of changes are OK to do seems quite
ingrained in jaroslav. i am worried what will happen when 1.0.0 comes
out, and then it *really* becomes unacceptable to do this kind of
thing any more than once a year (roughly speaking).

at the very least, move to pkgconfig so that apps can find the alsa
libs easily.

--p



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Takashi Iwai]

At Wed, 18 Sep 2002 14:21:44 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Wed, 18 Sep 2002, [iso-8859-1] Chris Rankin wrote:
> 
> >  --- Jaroslav Kysela <perex@perex.cz> wrote: > On Wed,
> > 18 Sep 2002, Chris Rankin wrote:
> > > Note: If
> > > SND_COMPATIBILITY_BUILD_RC3 is defined, 
> > > then applications need to fall back to 0.9.0rc3 API
> > > as well.
> > 
> > So maybe we could have a --with-compat-rc3 option for
> > alsa-utils as well? Regardless of which alsa-lib I
> > build, I always need to be able to build alsa-utils.
> > And I doubt that wine and xine will get updated before
> > -rc4 is released. (Unless there's a document somewhere
> > explaining the relationship between the old and new
> > API functions, in which case I could submit patches
> > myself.)
> 
> It seems, that you're not understand the compatibility.
> 
> 1) build library with --with-compat-rc3 and place it to some
>    other directory
> 3) build library without --with-compat-rc3, place it to
>    /usr/lib as usuall
> 4) build alsa-utils and newer applications
> 5) build older applications with compatible library compiled
>    with --with-compat-rc3
> 
> Old and new software will co-exist without any problems. Perhaps, we
> can have some good default place for rc3 compatible library and add an 
> autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3 
> directory for this job. Comments?

well, i think this is too complicated.  if we need two lib binaries,
then let's use different so numbers, not the different paths.

i.e.

compat-rc3 --> build libasound.so.2 without versioned symbols.
new lib    --> build libasound.so.3 with versioned symbols for
               the future confliction.


and how about to separate the function declarations of these two
versions into individual parts (or files) instead of combined
declarations with a macro (or ifdef)?  the old functions will be never
changed in future.


... but still i'd prefer adding new functions (or changing the whole
snd_pcm_hw_params_xxx to different names such like
snd_pcm_hw_setup_xxx to avoid confliction) to modifying the existing
api functions.  so there will be no compatibility problem at this
time.


ciao,

Takashi


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Jack O'Quin]

Jaroslav,

I must respectfully point out that your response proves that there
*is* a problem.  This solution is *compicated*.  You're a smart guy.
You probably feel you understand all its implications.  Perhaps you
do.  But, most ALSA users and developers *do not* and *will not*.

I am sorry to report that ALSA has a bad reputation on other forums
(like debian-users).  People appreciate the technology, but they can't
get it working, usually because of some silly problem like this one.
For every "clueless newbie" who asks for help on alsa-users there are
nine more who just shrug their shoulders and give up on ALSA.

ALSA 0.9.0-rc3 was released with a trivial mistake that prevented the
source from even compiling.  We should have immediately released rc4
with a fix for this error.  Instead, we're replacing the broken rc3
source with an rc4 that requires changes in source or configuration to
compile anything.  Pretty soon, no one outside this list is even going
to take ALSA 0.9.0 seriously.  If we don't, why should they?

Clearly, making this non-release-critical interface cleanup has
created a release-critical level of confusion.

I ask you again: *please* back out this change.

Jaroslav Kysela <perex@perex.cz> writes:
> It seems, that you're not understand the compatibility.
> 
> 1) build library with --with-compat-rc3 and place it to some
>    other directory
> 3) build library without --with-compat-rc3, place it to
>    /usr/lib as usuall
> 4) build alsa-utils and newer applications
> 5) build older applications with compatible library compiled
>    with --with-compat-rc3
> 
> Old and new software will co-exist without any problems. Perhaps, we
> can have some good default place for rc3 compatible library and add an 
> autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3 
> directory for this job. Comments?

-- 
  Jack O'Quin
  Austin, Texas, USA
  http://www.stellajazz.com


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Jaroslav Kysela]

Hi all,

	your almost all negative messages persuaded me to wait awhile with 
new function prototypes. Here is the result:

- .so library number returned to .2
- library builds with versioned symbols since now, default tag is ALSA_0.9
- new snd_pcm_hw_params_* function are available with tag ALSA_0.9.0rc4 
  (not available for default linking); these new functions are explicitly
  available when ALSA_PCM_NEW_HW_PARAMS_API is defined before inclusion of
  asoundlib.h
- old (default, implicit) functions are not documented from this time, 
  each references in documentation are to newer API

These changes allows us to use newer API (first change for ALSA 1.0) now
without any constraints for old and new APIs. The alsa-utils and
alsa-tools programs use new API since now.

Let me know, if you have some usage problem, but I hope that this library 
will behave in same way as 0.9.0rc3 does.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: new "in-compatible" alsa-lib PCM API

[Jack O'Quin]

Jaroslav Kysela <perex@perex.cz> writes:

> 	your almost all negative messages persuaded me to wait awhile with 
> new function prototypes. 

Thanks for listening, Jaroslav.  :-)

I intended my comments to be "negative" only in the narrow sense
("let's don't do this"), and not in the broader meanings of
"obstructive" or "pessimistic".

You're doing an important job, and we all appreciate it.

Regards,
-- 
  Jack O'Quin
  Austin, Texas, USA
  http://www.stellajazz.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: new "in-compatible" alsa-lib PCM API

[Takashi Iwai]

Hi Jaroslav,

At Thu, 19 Sep 2002 17:29:48 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> Hi all,
> 
> 	your almost all negative messages persuaded me to wait awhile with 
> new function prototypes. Here is the result:

thanks for quick reaction.
the new library works fine with the old applications.

> 
> - .so library number returned to .2

fine, we can keep the old apps.

> - library builds with versioned symbols since now, default tag is ALSA_0.9
> - new snd_pcm_hw_params_* function are available with tag ALSA_0.9.0rc4 
>   (not available for default linking); these new functions are explicitly
>   available when ALSA_PCM_NEW_HW_PARAMS_API is defined before inclusion of
>   asoundlib.h

will this condition be removed in the future release as default?
we can put ALSA_PCM_OLD_HW_PARAM_API for the backward compatibility
later, instead.

> - old (default, implicit) functions are not documented from this time, 
>   each references in documentation are to newer API

it would be nice to put a note that this api was changed since
0.9.0rc2.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: new "in-compatible" alsa-lib PCM API

[Kai Vehmanen]

On Fri, 20 Sep 2002, Takashi Iwai wrote:

>> 	your almost all negative messages persuaded me to wait awhile with 
>> new function prototypes. Here is the result:
> thanks for quick reaction.
> the new library works fine with the old applications.

Btw; with ld from binutils-2.9.5.0.22-6 (rh62) I get the
following error when linking libasound:

/usr/bin/ld: .libs/libasound.so.2.0.0: undefined versioned symbol name snd_pcm_hw_params_get_rate_min@ALSA_0.9.0rc4
/usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status

And this with a fresh CVS-update of alsa-lib. Might
be a clear ld bug. 

>>   (not available for default linking); these new functions are explicitly
>>   available when ALSA_PCM_NEW_HW_PARAMS_API is defined before inclusion of
> will this condition be removed in the future release as default?
> we can put ALSA_PCM_OLD_HW_PARAM_API for the backward compatibility
> later, instead.

It's too bad there isn't better language-level support for versioned
interfaces. You can do all kinds of things with the preprocessor and
linker, but this really should be something all developers are all aware
of and know how to use.

The basic scenario is:

1. library implements a set of interfaces (v1, v2, ...) 
2. application using the library uses one of the
   interface versions (and note, it's important that 
   application code always explicitly defines what
   interface is wants to use)

Age of each interface should span multiple major releases of the library,
but not nocessarily more than that (maintaining (especially testing!) more
than two or three different versions in the same physical package starts
to be a mess).

This scenario has numerous benefits:

- application developer can decide the time when 
  to port from interface x to x+1 (note! after
  the change, app will then require library 
  version x+1 to be installed)
- library developer can continue to improve 
  the library interfaces without causing
  suprises to app developers

Unfortunately implementing the above is anything but easy. Although there
are mechanisms to do (1) (ld scripts, shared-lib versioning), they add
significant overhead to the maintenance work.

But the real problem is (2). There are no commonly used mechanisms for
applications to announce what interface versions of an library package
they want to use. Installing library versions to different directories is
one option, but certainly not an easy one (application developers are not
the ones writing library installation scripts).

Another approach for (2) is the one now used by alsa-lib. In other words,
before including the library headers, we define what library interface
version we want to use.

So should we make this into a standard practise? In other words all apps
should define SND_PCM_SELECT_API_X, where X is the version number, before
including asoundlib.h. This would provide a framework for future API
extensions and changes (there's bound to be some, sooner or later).
If an app tries to select an interface that has already been dropped
from the latest alsa-lib, the compiler can then print an informative 
error message about the problem.

But as I mentioned in the beginning, a good argument against this
is that we are talking about a non-standard feature. Without good 
and visible documentation, developers don't know how to use the
SND_PCM_SELECT_API_X API selector. Ugh. :(

--
 http://www.eca.cx
 Audio software for Linux!
 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: new "in-compatible" alsa-lib PCM API

[Jaroslav Kysela]

On Fri, 20 Sep 2002, Kai Vehmanen wrote:

> On Fri, 20 Sep 2002, Takashi Iwai wrote:
> 
> >> 	your almost all negative messages persuaded me to wait awhile with 
> >> new function prototypes. Here is the result:
> > thanks for quick reaction.
> > the new library works fine with the old applications.
> 
> Btw; with ld from binutils-2.9.5.0.22-6 (rh62) I get the
> following error when linking libasound:
> 
> /usr/bin/ld: .libs/libasound.so.2.0.0: undefined versioned symbol name snd_pcm_hw_params_get_rate_min@ALSA_0.9.0rc4
> /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status
> 
> And this with a fresh CVS-update of alsa-lib. Might
> be a clear ld bug. 

What's result of this command?
	nm alsa/lib/src/pcm.lo | grep snd_pcm_hw_params_get_rate_min

> >>   (not available for default linking); these new functions are explicitly
> >>   available when ALSA_PCM_NEW_HW_PARAMS_API is defined before inclusion of
> > will this condition be removed in the future release as default?
> > we can put ALSA_PCM_OLD_HW_PARAM_API for the backward compatibility
> > later, instead.
> 
> It's too bad there isn't better language-level support for versioned
> interfaces. You can do all kinds of things with the preprocessor and
> linker, but this really should be something all developers are all aware
> of and know how to use.
> 
> The basic scenario is:
> 
> 1. library implements a set of interfaces (v1, v2, ...) 
> 2. application using the library uses one of the
>    interface versions (and note, it's important that 
>    application code always explicitly defines what
>    interface is wants to use)
> 
> Age of each interface should span multiple major releases of the library,
> but not nocessarily more than that (maintaining (especially testing!) more
> than two or three different versions in the same physical package starts
> to be a mess).

I agree, but the current change is really mostly cosmetic. The enhancement 
is the returned error value and unified casting for passed/retured values.
The library code works internally already with new functions, so the 
overhead is minimal (only add conversion functions for older API).
I already noted, if API behaviour changes, then it's major change and 
we'll increase the major library number, but it's definitely a thing for 
1.0 development tree.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: new "in-compatible" alsa-lib PCM API

[Fernando Pablo Lopez-Lezcano]

> > > Note: If
> > > SND_COMPATIBILITY_BUILD_RC3 is defined,
> > > then applications need to fall back to 0.9.0rc3 API
> > > as well.
> >
> > So maybe we could have a --with-compat-rc3 option for
> > alsa-utils as well? Regardless of which alsa-lib I
> > build, I always need to be able to build alsa-utils.
> > And I doubt that wine and xine will get updated before
> > -rc4 is released. (Unless there's a document somewhere
> > explaining the relationship between the old and new
> > API functions, in which case I could submit patches
> > myself.)
>
> It seems, that you're not understand the compatibility.
>
> 1) build library with --with-compat-rc3 and place it to some
> other directory

No, no and no. No need to if the versions of the library are
different. And they better be different!! They should go into
prefix/lib (normally /usr/lib) so that older applications keep
working until they are recompiled with the new version of the
api.

> 3) build library without --with-compat-rc3, place it to
> /usr/lib as usuall
> 4) build alsa-utils and newer applications
> 5) build older applications with compatible library compiled
> with --with-compat-rc3

Let me see if I understand, after all the compiling and
installing is done we have two shared libraries with different
versions in /usr/lib, and one set of header files in
/usr/include, and the behavior of the header files depends on
SND_COMPATIBILITY_BUILD_RC3 being defined (if it is defined
then the old prototype/api is used, if not then the new
prototype/api is used). So:

- old applications that use the old .so number keep working
- new applications that understand the new api can be
  compiled and linked as usual and they work with the new .so
  library.
- old applications that have to be recompiled can be
  recompiled with the old api if they define
  SND_COMPATIBILITY_BUILD_RC3

  [but how do they pick the older .so library over the new
  one at link time?, remember, they are in the same place, does
  this need any extra tricks or it just "happens"?]

Ok, so this is better than nothing, but I still have to say:

This is supposed to be 0.9.0rc3 going on 0.9.0rc4.
This is not 0.6 cvs.

NO API CHANGES PLEASE!!!!!!!!!!
Only bug fixes, new drivers maybe. RC releases are release
candidates, they are supposed to be stabilizing the thing! (in
my understanding)

Furthermore, I found about the api change by _chance_, because
I was testing the latest cvs versions (which have better usb
midi support) and for some reason tried to recompile jack and
it would not compile! I could not believe my eyes.

IF 0.9.0rc3 really means "release candidate 3" then this
change is not acceptable. Nothing is "broken" in the api,
nothing (AFAIK) _needs_ to be fixed or else applications will
not work. This is not new functionality. This is a style
change, to make things prettier and more consistent (which of
course I like). For any api change at any time, at the very
least developers have to be WARNED about the changes. In an
rc3 it should be mandatory (I mean, if you insist on changing
the api when it should be stable). Otherwise lets rename the
version to 0.8 or whatever.

I have to echo the previous comment on this thread: if we
still have an rc3 tarball in the web site that does not
compile out of the box then there is something wrong. Do we
want alsa adopted? Do we think that will happen if people
download it and cannot even compile it?? (no, the warning in
the site is NOT enough - witness the number of emails sent to
the list about this).

Sorry for the rant.

I understand that the sooner an api change is made the better,
but, again, this is rc3 and things are supposed to be stable
NOW.

As was mentioned before, create a NEW set of api calls, mark
the old ones as deprecated and erase them after two or three
releases. And document the improved api in a very distinctive
way, otherwise developers will not even notice the change.

-- Fernando


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Chris Rankin]

 --- Jaroslav Kysela <perex@perex.cz> wrote: > On Wed,
18 Sep 2002, [iso-8859-1] Chris Rankin
> wrote:
>> It seems, that you're not understand the
> compatibility.

That's possible - or maybe the existing
"compatibility" is woefully inadequate for the scale
of the problem?

The applications that I am trying to compile with the
compatibility library are the CVS versions of wine and
xine!!! I can't just recompile them and forget about
them because I need the compatibility headers
installed so that I can KEEP recompiling them as I
update them! However, the ALSA utilities don't compile
against the compatibility headers because they are
incompatible!

The possible solutions from my perspective are:
- I install BOTH libraries, each with full headers
(somehow)
- I backport the ALSA utilities to work with the old
API
- I forward port xine and wine to the new API myself
- You back out the incompatible API.

Sincerely,
Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Chris Rankin]

 --- Chris Rankin <rankincj@yahoo.com> wrote: >  ---
Jaroslav Kysela <perex@perex.cz> wrote: > On
> The possible solutions from my perspective are:
> - I install BOTH libraries, each with full headers
> (somehow)

Oh yes, and the compatibility version has to go in
/usr because that's where the rest of the world
expects to find the ALSA headers.

Chris


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: new "in-compatible" alsa-lib PCM API

[Ville Syrjälä]

On Wed, Sep 18, 2002 at 01:02:35PM +0100, Chris Rankin wrote:
> So maybe we could have a --with-compat-rc3 option for
> alsa-utils as well?

I don't think there has been any other changes. Just use rc3 alsa-utils.

> And I doubt that wine and xine will get updated before
> -rc4 is released.

> (Unless there's a document somewhere
> explaining the relationship between the old and new
> API functions, in which case I could submit patches
> myself.)

As I understand it the change was pretty trivial. Just compare the header
files or aplay for example. Or just don't use the latest cvs stuff.

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


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab