* [ALSA - lib 0001034]: (potential) problems introduced with the " improved stream linking and plugin code cleanups" patch by perex
@ 2005-04-03 15:42 bugtrack
0 siblings, 0 replies; 4+ messages in thread
From: bugtrack @ 2005-04-03 15:42 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1034>
======================================================================
Reported By: modax
Assigned To:
======================================================================
Project: ALSA - lib
Issue ID: 1034
Category: pcm - digital audio
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 04-03-2005 17:42 CEST
Last Modified: 04-03-2005 17:42 CEST
======================================================================
Summary: (potential) problems introduced with the " improved
stream linking and plugin code cleanups" patch by perex
Description:
I'm not an alsa developer so I hadn't known anything about alsa internals
up until I started debugging alsa-lib to fix an annoying bug I was having
with alsa 1.0.9rc1 and above. I'm not sure whether my patch/suggestions
are 100% correct or the best way fix to those bugs.
The initial problem I'm refering to is described in bug#1009 note
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0004275. I narrowed my
search of the regression down to the big patch,
which was submitted to alsa-lib CVS on 2005-01-20 by perex. The patch
cleans up plugin code. Unfortunately, some things have been overlooked by
the author. Firstly, I'll start with my problem and a fix for it.
As I described in note
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0004275, I had problems
with -Dsurround51 on my
NFORCE board. The root of the problem was a combination of two plugins -
route and hooks - used in surround51 configuration. Later I learned, that
removing one of them helped, but they both wouldn't work. The portion of
code which is to blame for the regression can be seen in
hooks-channel-info-fix.patch (attached). Just compare the original
pcm_hooks.c:snd_pcm_hooks_channel_info() (before "2005-01-20" patch) and
pcm_generic.c:snd_pcm_generic_channel_info(), which was supposed to
replace it. They are completely different functions. Other plugins which
are likely to suffer from the same bug are:
* pcm_file.c
* pcm_plug.c
However, most other plugins used
pcm_plugin.c:snd_pcm_plugin_channel_info() before the "2005-01-20" patch.
It shares the same code with snd_pcm_generic_channel_info(). So this issue
raises a few question:
* Is snd_pcm_generic_channel() as it is now valid? At least pcm_hooks
and likely pcm_file and pcm_plug don't work with it.
* If it's valid, there is a necessity to create another generic
function, which clones the code previously provided by
snd_pcm_{hooks,file,plug}_channel_info() functions.
The attached patch solves the problem for me, but it is not an universal
solution. The patch should be applied against CVS as of 2005-01-21 or
later.
And now here it comes some other remarks regarding the "2005-01-20"
patch.
* I guess, snd_pcm_plugin_fast_ops.status = snd_pcm_generic_status in
pcm_plugin.c is incorrect because it makes snd_pcm_plugin_status()
reduntant and these functions don't share the same code.
* Plugins which haven't been "cleaned up" by the "2005-01-20" patch
include:
- pcm_meter.c
- pcm_null.c
- pcm_share.c
- pcm_shm.c
The latter two seem to be kinda different beasts whereas the first two
shouldn't be too difficult to "_generic_"'ize.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-03-05 17:42 modax New Issue
04-03-05 17:42 modax File Added: hooks-channel-info-fix.diff
======================================================================
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ALSA - lib 0001034]: (potential) problems introduced with the " improved stream linking and plugin code cleanups" patch by perex
@ 2005-04-03 15:53 bugtrack
0 siblings, 0 replies; 4+ messages in thread
From: bugtrack @ 2005-04-03 15:53 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1034>
======================================================================
Reported By: modax
Assigned To:
======================================================================
Project: ALSA - lib
Issue ID: 1034
Category: pcm - digital audio
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 04-03-2005 17:42 CEST
Last Modified: 04-03-2005 17:53 CEST
======================================================================
Summary: (potential) problems introduced with the " improved
stream linking and plugin code cleanups" patch by perex
Description:
I'm not an alsa developer so I hadn't known anything about alsa internals
up until I started debugging alsa-lib to fix an annoying bug I was having
with alsa 1.0.9rc1 and above. I'm not sure whether my patch/suggestions
are 100% correct or the best way fix to those bugs.
The initial problem I'm refering to is described in bug#1009 note
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0004275. I narrowed my
search of the regression down to the big patch,
which was submitted to alsa-lib CVS on 2005-01-20 by perex. The patch
cleans up plugin code. Unfortunately, some things have been overlooked by
the author. Firstly, I'll start with my problem and a fix for it.
As I described in note
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0004275, I had problems
with -Dsurround51 on my
NFORCE board. The root of the problem was a combination of two plugins -
route and hooks - used in surround51 configuration. Later I learned, that
removing one of them helped, but they both wouldn't work. The portion of
code which is to blame for the regression can be seen in
hooks-channel-info-fix.patch (attached). Just compare the original
pcm_hooks.c:snd_pcm_hooks_channel_info() (before "2005-01-20" patch) and
pcm_generic.c:snd_pcm_generic_channel_info(), which was supposed to
replace it. They are completely different functions. Other plugins which
are likely to suffer from the same bug are:
* pcm_file.c
* pcm_plug.c
However, most other plugins used
pcm_plugin.c:snd_pcm_plugin_channel_info() before the "2005-01-20" patch.
It shares the same code with snd_pcm_generic_channel_info(). So this issue
raises a few question:
* Is snd_pcm_generic_channel() as it is now valid? At least pcm_hooks
and likely pcm_file and pcm_plug don't work with it.
* If it's valid, there is a necessity to create another generic
function, which clones the code previously provided by
snd_pcm_{hooks,file,plug}_channel_info() functions.
The attached patch solves the problem for me, but it is not an universal
solution. The patch should be applied against CVS as of 2005-01-21 or
later.
And now here it comes some other remarks regarding the "2005-01-20"
patch.
* I guess, snd_pcm_plugin_fast_ops.status = snd_pcm_generic_status in
pcm_plugin.c is incorrect because it makes snd_pcm_plugin_status()
reduntant and these functions don't share the same code.
* Plugins which haven't been "cleaned up" by the "2005-01-20" patch
include:
- pcm_meter.c
- pcm_null.c
- pcm_share.c
- pcm_shm.c
The latter two seem to be kinda different beasts whereas the first two
shouldn't be too difficult to "_generic_"'ize.
======================================================================
----------------------------------------------------------------------
modax - 04-03-05 17:53
----------------------------------------------------------------------
I wonder where my alsa/os info has disappered. The bug applies to alsa-lib
1.0.8+cvs20050121 and later. I'm running Debian unstable and Linux kernel
2.6.11.5 with alsa-driver 1.0.9rc2+cvs20050330
Issue History
Date Modified Username Field Change
======================================================================
04-03-05 17:42 modax New Issue
04-03-05 17:42 modax File Added: hooks-channel-info-fix.diff
04-03-05 17:53 modax Note Added: 0004312
======================================================================
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ALSA - lib 0001034]: (potential) problems introduced with the " improved stream linking and plugin code cleanups" patch by perex
@ 2005-04-05 16:07 bugtrack
0 siblings, 0 replies; 4+ messages in thread
From: bugtrack @ 2005-04-05 16:07 UTC (permalink / raw)
To: alsa-devel
The following issue has been RESOLVED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1034>
======================================================================
Reported By: modax
Assigned To: tiwai
======================================================================
Project: ALSA - lib
Issue ID: 1034
Category: pcm - digital audio
Reproducibility: always
Severity: major
Priority: normal
Status: resolved
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 04-03-2005 17:42 CEST
Last Modified: 04-05-2005 18:07 CEST
======================================================================
Summary: (potential) problems introduced with the " improved
stream linking and plugin code cleanups" patch by perex
Description:
I'm not an alsa developer so I hadn't known anything about alsa internals
up until I started debugging alsa-lib to fix an annoying bug I was having
with alsa 1.0.9rc1 and above. I'm not sure whether my patch/suggestions
are 100% correct or the best way fix to those bugs.
The initial problem I'm refering to is described in bug#1009 note
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0004275. I narrowed my
search of the regression down to the big patch,
which was submitted to alsa-lib CVS on 2005-01-20 by perex. The patch
cleans up plugin code. Unfortunately, some things have been overlooked by
the author. Firstly, I'll start with my problem and a fix for it.
As I described in note
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0004275, I had problems
with -Dsurround51 on my
NFORCE board. The root of the problem was a combination of two plugins -
route and hooks - used in surround51 configuration. Later I learned, that
removing one of them helped, but they both wouldn't work. The portion of
code which is to blame for the regression can be seen in
hooks-channel-info-fix.patch (attached). Just compare the original
pcm_hooks.c:snd_pcm_hooks_channel_info() (before "2005-01-20" patch) and
pcm_generic.c:snd_pcm_generic_channel_info(), which was supposed to
replace it. They are completely different functions. Other plugins which
are likely to suffer from the same bug are:
* pcm_file.c
* pcm_plug.c
However, most other plugins used
pcm_plugin.c:snd_pcm_plugin_channel_info() before the "2005-01-20" patch.
It shares the same code with snd_pcm_generic_channel_info(). So this issue
raises a few question:
* Is snd_pcm_generic_channel() as it is now valid? At least pcm_hooks
and likely pcm_file and pcm_plug don't work with it.
* If it's valid, there is a necessity to create another generic
function, which clones the code previously provided by
snd_pcm_{hooks,file,plug}_channel_info() functions.
The attached patch solves the problem for me, but it is not an universal
solution. The patch should be applied against CVS as of 2005-01-21 or
later.
And now here it comes some other remarks regarding the "2005-01-20"
patch.
* I guess, snd_pcm_plugin_fast_ops.status = snd_pcm_generic_status in
pcm_plugin.c is incorrect because it makes snd_pcm_plugin_status()
reduntant and these functions don't share the same code.
* Plugins which haven't been "cleaned up" by the "2005-01-20" patch
include:
- pcm_meter.c
- pcm_null.c
- pcm_share.c
- pcm_shm.c
The latter two seem to be kinda different beasts whereas the first two
shouldn't be too difficult to "_generic_"'ize.
======================================================================
----------------------------------------------------------------------
modax - 04-03-05 17:53
----------------------------------------------------------------------
I wonder where my alsa/os info has disappered. The bug applies to alsa-lib
1.0.8+cvs20050121 and later. I'm running Debian unstable and Linux kernel
2.6.11.5 with alsa-driver 1.0.9rc2+cvs20050330
----------------------------------------------------------------------
tiwai - 04-05-05 18:07
----------------------------------------------------------------------
Thanks for reports. I fixed this on CVS in the similar way.
snd_pcm_generic_channel_info_slave() is added to be called from these
three plugins.
Issue History
Date Modified Username Field Change
======================================================================
04-03-05 17:42 modax New Issue
04-03-05 17:42 modax File Added: hooks-channel-info-fix.diff
04-03-05 17:53 modax Note Added: 0004312
04-05-05 18:07 tiwai Status new => resolved
04-05-05 18:07 tiwai Resolution open => fixed
04-05-05 18:07 tiwai Assigned To => tiwai
04-05-05 18:07 tiwai Note Added: 0004338
======================================================================
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ALSA - lib 0001034]: (potential) problems introduced with the " improved stream linking and plugin code cleanups" patch by perex
@ 2005-07-08 8:38 bugtrack
0 siblings, 0 replies; 4+ messages in thread
From: bugtrack @ 2005-07-08 8:38 UTC (permalink / raw)
To: alsa-devel
The following issue has been CLOSED
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1034>
======================================================================
Reported By: modax
Assigned To: tiwai
======================================================================
Project: ALSA - lib
Issue ID: 1034
Category: 1_pcm - digital audio
Reproducibility: always
Severity: major
Priority: normal
Status: closed
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 04-03-2005 17:42 CEST
Last Modified: 07-08-2005 10:38 CEST
======================================================================
Summary: (potential) problems introduced with the " improved
stream linking and plugin code cleanups" patch by perex
Description:
I'm not an alsa developer so I hadn't known anything about alsa internals
up until I started debugging alsa-lib to fix an annoying bug I was having
with alsa 1.0.9rc1 and above. I'm not sure whether my patch/suggestions
are 100% correct or the best way fix to those bugs.
The initial problem I'm refering to is described in bug#1009 note
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0004275. I narrowed my
search of the regression down to the big patch,
which was submitted to alsa-lib CVS on 2005-01-20 by perex. The patch
cleans up plugin code. Unfortunately, some things have been overlooked by
the author. Firstly, I'll start with my problem and a fix for it.
As I described in note
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0004275, I had problems
with -Dsurround51 on my
NFORCE board. The root of the problem was a combination of two plugins -
route and hooks - used in surround51 configuration. Later I learned, that
removing one of them helped, but they both wouldn't work. The portion of
code which is to blame for the regression can be seen in
hooks-channel-info-fix.patch (attached). Just compare the original
pcm_hooks.c:snd_pcm_hooks_channel_info() (before "2005-01-20" patch) and
pcm_generic.c:snd_pcm_generic_channel_info(), which was supposed to
replace it. They are completely different functions. Other plugins which
are likely to suffer from the same bug are:
* pcm_file.c
* pcm_plug.c
However, most other plugins used
pcm_plugin.c:snd_pcm_plugin_channel_info() before the "2005-01-20" patch.
It shares the same code with snd_pcm_generic_channel_info(). So this issue
raises a few question:
* Is snd_pcm_generic_channel() as it is now valid? At least pcm_hooks
and likely pcm_file and pcm_plug don't work with it.
* If it's valid, there is a necessity to create another generic
function, which clones the code previously provided by
snd_pcm_{hooks,file,plug}_channel_info() functions.
The attached patch solves the problem for me, but it is not an universal
solution. The patch should be applied against CVS as of 2005-01-21 or
later.
And now here it comes some other remarks regarding the "2005-01-20"
patch.
* I guess, snd_pcm_plugin_fast_ops.status = snd_pcm_generic_status in
pcm_plugin.c is incorrect because it makes snd_pcm_plugin_status()
reduntant and these functions don't share the same code.
* Plugins which haven't been "cleaned up" by the "2005-01-20" patch
include:
- pcm_meter.c
- pcm_null.c
- pcm_share.c
- pcm_shm.c
The latter two seem to be kinda different beasts whereas the first two
shouldn't be too difficult to "_generic_"'ize.
======================================================================
----------------------------------------------------------------------
modax - 04-03-05 17:53
----------------------------------------------------------------------
I wonder where my alsa/os info has disappered. The bug applies to alsa-lib
1.0.8+cvs20050121 and later. I'm running Debian unstable and Linux kernel
2.6.11.5 with alsa-driver 1.0.9rc2+cvs20050330
----------------------------------------------------------------------
tiwai - 04-05-05 18:07
----------------------------------------------------------------------
Thanks for reports. I fixed this on CVS in the similar way.
snd_pcm_generic_channel_info_slave() is added to be called from these
three plugins.
Issue History
Date Modified Username Field Change
======================================================================
04-03-05 17:42 modax New Issue
04-03-05 17:42 modax File Added: hooks-channel-info-fix.diff
04-03-05 17:53 modax Note Added: 0004312
04-05-05 18:07 tiwai Status new => resolved
04-05-05 18:07 tiwai Resolution open => fixed
04-05-05 18:07 tiwai Assigned To => tiwai
04-05-05 18:07 tiwai Note Added: 0004338
07-08-05 10:38 perex Status resolved => closed
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-07-08 8:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-03 15:53 [ALSA - lib 0001034]: (potential) problems introduced with the " improved stream linking and plugin code cleanups" patch by perex bugtrack
-- strict thread matches above, loose matches on Subject: below --
2005-07-08 8:38 bugtrack
2005-04-05 16:07 bugtrack
2005-04-03 15:42 bugtrack
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox