backwards incompatible ALSA api change?

backwards incompatible ALSA api change?

[Fernando Pablo Lopez-Lezcano]

[sent also to alsa-dev - maybe I missed an announcement about this?]

The jack (Jack Audio Connection Kit, cvs from around the beginning of
September) code no longer compiles with the most recent alsa cvs:

alsa_driver.c: In function `alsa_driver_set_parameters':
alsa_driver.c:403: too few arguments to function 
`snd_pcm_hw_params_get_format'
alsa_driver.c:404: too few arguments to function 
`snd_pcm_hw_params_get_access'
alsa_driver.c:416: too few arguments to function 
`snd_pcm_hw_params_get_format'
alsa_driver.c:417: too few arguments to function 
`snd_pcm_hw_params_get_access'

There has been a backwards incompatible alsa api change. This is recent, I
guess, it compiles with cvs of 20020820.180035 (USA Pacific time). I know
there MUST a perfectly good reason for a backwards incompatible api change
at this point (some new extended format structure?), but may I say,
respectfully, something?

 ARGHHHHHHHHHH!!!!!

:-)

When trying to run a jack server with a newly compiled alsa driver and 
library I get a not very informative diagnostic from jack:

  jackd 0.37.2
  Copyright 2001-2002 Paul Davis and others.
  jackd comes with ABSOLUTELY NO WARRANTY
  This is free software, and you are welcome to redistribute it
  under certain conditions; see the file COPYING for details

  creating alsa driver ... hw|1024|2|48000|swmon
  programming error: unhandled format type

It is not segfaulting (why? is it just chance that it did not?)

To the alsa gurus: could a message be sent to alsa-dev when there are
backwards incompatible changes in the API please? It'd be good to know, I
think (at least _I_ would like to know). Please?

-- Fernando



-------------------------------------------------------
In remembrance
www.osdn.com/911/

Re: backwards incompatible ALSA api change?

[Takashi Iwai]

At Tue, 10 Sep 2002 20:42:46 -0700 (PDT),
Fernando Pablo Lopez-Lezcano wrote:
> 
> [sent also to alsa-dev - maybe I missed an announcement about this?]
> 
> The jack (Jack Audio Connection Kit, cvs from around the beginning of
> September) code no longer compiles with the most recent alsa cvs:
> 
> alsa_driver.c: In function `alsa_driver_set_parameters':
> alsa_driver.c:403: too few arguments to function 
> `snd_pcm_hw_params_get_format'
> alsa_driver.c:404: too few arguments to function 
> `snd_pcm_hw_params_get_access'
> alsa_driver.c:416: too few arguments to function 
> `snd_pcm_hw_params_get_format'
> alsa_driver.c:417: too few arguments to function 
> `snd_pcm_hw_params_get_access'
> 
> There has been a backwards incompatible alsa api change. This is recent, I
> guess, it compiles with cvs of 20020820.180035 (USA Pacific time). I know
> there MUST a perfectly good reason for a backwards incompatible api change
> at this point (some new extended format structure?), but may I say,
> respectfully, something?
> 
>  ARGHHHHHHHHHH!!!!!
> 
> :-)

ouch, i found that Jaroslav changed the functions above yesterday on
cvs.

the old one:
int snd_pcm_hw_params_get_format(const snd_pcm_hw_params_t *params);

the new one:
int snd_pcm_hw_params_get_format(const snd_pcm_hw_params_t *params, snd_pcm_format_t *val);

same are for subformat and access.

i understand the reason why it was changed.  the new one looks more
consistent.  but snd_pcm_format_t is enum, so it should be identical
with int at any rate.
(possibly c++ may complain about the difference between them, though.)

i don't think it's a good idea to change such a basic api function at
this time.  the old one works fine, and we'll have never negative
values for format, etc.  this change will give more pain than gain.

Jaroslav, could you consider to get them back to the old style?

> When trying to run a jack server with a newly compiled alsa driver and 
> library I get a not very informative diagnostic from jack:
> 
>   jackd 0.37.2
>   Copyright 2001-2002 Paul Davis and others.
>   jackd comes with ABSOLUTELY NO WARRANTY
>   This is free software, and you are welcome to redistribute it
>   under certain conditions; see the file COPYING for details
> 
>   creating alsa driver ... hw|1024|2|48000|swmon
>   programming error: unhandled format type
>  
> It is not segfaulting (why? is it just chance that it did not?)

marphy's law :)

> To the alsa gurus: could a message be sent to alsa-dev when there are
> backwards incompatible changes in the API please? It'd be good to know, I
> think (at least _I_ would like to know). Please?

usually such a change appears on alsa cvs annoucement, but this
did't by unknown reason...


Takashi


-------------------------------------------------------
In remembrance
www.osdn.com/911/

Re: backwards incompatible ALSA api change?

[Fernando Pablo Lopez-Lezcano]

> > [sent also to alsa-dev - maybe I missed an announcement about this?]
> >
> > The jack (Jack Audio Connection Kit, cvs from around the beginning of
> > September) code no longer compiles with the most recent alsa cvs:
> >
> > There has been a backwards incompatible alsa api change. This is recent, I
> > guess, it compiles with cvs of 20020820.180035 (USA Pacific time). I know
> > there MUST a perfectly good reason for a backwards incompatible api change
> > at this point (some new extended format structure?), but may I say,
> > respectfully, something?
> >
> > ARGHHHHHHHHHH!!!!!
>
> ouch, i found that Jaroslav changed the functions above yesterday on
> cvs.
>
> the old one:
> int snd_pcm_hw_params_get_format(const snd_pcm_hw_params_t *params);
>
> the new one:
> int snd_pcm_hw_params_get_format(const snd_pcm_hw_params_t *params,
> snd_pcm_format_t *val);
>
> same are for subformat and access.
>
> i understand the reason why it was changed.  the new one looks more
> consistent.  but snd_pcm_format_t is enum, so it should be identical
> with int at any rate.
> (possibly c++ may complain about the difference between them, though.)
>
> i don't think it's a good idea to change such a basic api function at
> this time.  the old one works fine, and we'll have never negative
> values for format, etc.  this change will give more pain than gain.
>
> Jaroslav, could you consider to get them back to the old style?

Please please PLEASE?

If the change is not reverted I will personally have to patch
it back (what a pain!) to the way it was if I want to keep
trying cvs (<*> see below for more on why). The very recent
and ongoing changes happening in the very important usb audio
driver is an example of why using cvs (at least for me) is not
really a luxury.

Is there any internal side effect to reverting to the old
format with a patch?

If the API change is desirable and _has_ to be made there
should be an announcement (to alsa-dev which is where I assume
is where all developers of alsa applications are subscribed
to), and the library version should be increased so that an
application compiled with the old version will not just
segfault when run under the new drivers (maybe 0.9.1?,
0.9.0.1?).

> > To the alsa gurus: could a message be sent to alsa-dev when there are
> > backwards incompatible changes in the API please? It'd be good to know, I
> > think (at least _I_ would like to know). Please?
>
> usually such a change appears on alsa cvs annoucement, but this
> did't by unknown reason...

I am not subscribed to the cvs announcement list. At this
point in time I would say this an API change that will affect
all programs out there that use alsa should be prominently
sent to alsa-dev. Very prominently. The sooner developers know
what's coming up in the next release the better.

-- Fernando

<*> why would I have to patch things back....

If I want to try the new features or bugs of cvs alsa I would
have to either patch all the software I'm mantaining here at
ccrma, or be patient and wait for the developers of programs
to patch them to the new api.

At this point the list of packaged software that links against
libasound.so.2 includes from 15 to 20 (depending on how you
count) packages.

So, if a new feature in alsa cvs is very desirable I would
have to recompile all the applications and maybe change most
of them myself (if they use the affected functions).

That is not a HUGE undertaking but it is a BIG pain.

But the situation is a little different now, the work I do
mantaining ccrma is now reflected in the Planet CCRMA pages,
where these packages are being used by people outside ccrma.
If I want to upgrade the alsa driver at some point to a newer
cvs version (so that, for example, usb audio works better), I
would have to upgrade all packages and force a big upgrade on
all users.

I guess that is why I should not be even touching cvs :-) ;-) :-)


-------------------------------------------------------
In remembrance
www.osdn.com/911/

Re: backwards incompatible ALSA api change?

[Fernando Pablo Lopez-Lezcano]

> If the API change is desirable and _has_ to be made there
> should be an announcement (to alsa-dev which is where I assume
> is where all developers of alsa applications are subscribed
> to), and the library version should be increased so that an
> application compiled with the old version will not just
> segfault when run under the new drivers...

Correct me if I'm wrong but bumping the library version number
from .so.2 to .so.3 with api changes would also enable orderly
migration _if_ the interface between the library and the
drivers does not change. I would be able to have both a .so.2
and a .so.3 in the system, so that old, not yet converted
programs would work fine and new programs using the .so.3
library would also work. Eventually, when all programs are
updated and recompiled to use .so.3, the .so.2 could be just
erased and would be history. Am I dreaming?

-- Fernando

PS: I realize migration between versions is probably not a
priority at all for most people, but it is for me...


-------------------------------------------------------
In remembrance
www.osdn.com/911/

Re: backwards incompatible ALSA api change?

[Jaroslav Kysela]

On Wed, 11 Sep 2002, Fernando Pablo Lopez-Lezcano wrote:

> > If the API change is desirable and _has_ to be made there
> > should be an announcement (to alsa-dev which is where I assume
> > is where all developers of alsa applications are subscribed
> > to), and the library version should be increased so that an
> > application compiled with the old version will not just
> > segfault when run under the new drivers...
> 
> Correct me if I'm wrong but bumping the library version number
> from .so.2 to .so.3 with api changes would also enable orderly
> migration _if_ the interface between the library and the
> drivers does not change. I would be able to have both a .so.2
> and a .so.3 in the system, so that old, not yet converted
> programs would work fine and new programs using the .so.3
> library would also work. Eventually, when all programs are
> updated and recompiled to use .so.3, the .so.2 could be just
> erased and would be history. Am I dreaming?

Nope. I'll do that (it's already on my HDD), but I'll have to change more 
snd_pcm_hw_params_* functions to unify the access and let recognize
the error code to applications.

						Jaroslav

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



-------------------------------------------------------
In remembrance
www.osdn.com/911/

Re: backwards incompatible ALSA api change?

[Fernando Pablo Lopez-Lezcano]

> > Correct me if I'm wrong but bumping the library version number
> > from .so.2 to .so.3 with api changes would also enable orderly
> > migration _if_ the interface between the library and the
> > drivers does not change. I would be able to have both a .so.2
> > and a .so.3 in the system, so that old, not yet converted
> > programs would work fine and new programs using the .so.3
> > library would also work. Eventually, when all programs are
> > updated and recompiled to use .so.3, the .so.2 could be just
> > erased and would be history. Am I dreaming?
>
> Nope. I'll do that (it's already on my HDD), but I'll have to change more
> snd_pcm_hw_params_* functions to unify the access and let recognize
> the error code to applications.

Great, thanks a lot. It'd be helpful if you could you post a
small message to alsa-dev when you are done with that change
in cvs. Then I can try to get a build that has the "backwards
compatibility" old library and start migrating applications as
they become "aware" of the new library.

-- Fernando


-------------------------------------------------------
In remembrance
www.osdn.com/911/