* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-02 15:49 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-02 15:49 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-02-2005 16:49 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-02 16:39 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-02 16:39 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-02-2005 17:39 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
tiwai - 12-02-05 17:39
----------------------------------------------------------------------
1. Please make a unified diff against the latest ALSA version.
2. Note that the SPDIF output is supposed to be "spdif" PCM. If this PCM
is selected, the dxs 3 is selected automagically. Output to SPDIF though
the default PCM is a side-effect, and not guaranteed to work always.
3. It's wrong to toggle AC97 register bit in spdif_put callback. It
conflicts with "IEC958 Playback Switch".
4. "IEC958 Analog Playback" is nonsense. It's identical with "Capture
Source" control.
5. It's correct to restrict the output sample rates to
chip->ac97->rates[AC97_RATES_SPDIF] because the IEC958 itself supports
only limited sample rates (regardless what source you use).
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-03 20:18 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-03 20:18 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-03-2005 21:18 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
tiwai - 12-02-05 17:39
----------------------------------------------------------------------
1. Please make a unified diff against the latest ALSA version.
2. Note that the SPDIF output is supposed to be "spdif" PCM. If this PCM
is selected, the dxs 3 is selected automagically. Output to SPDIF though
the default PCM is a side-effect, and not guaranteed to work always.
3. It's wrong to toggle AC97 register bit in spdif_put callback. It
conflicts with "IEC958 Playback Switch".
4. "IEC958 Analog Playback" is nonsense. It's identical with "Capture
Source" control.
5. It's correct to restrict the output sample rates to
chip->ac97->rates[AC97_RATES_SPDIF] because the IEC958 itself supports
only limited sample rates (regardless what source you use).
----------------------------------------------------------------------
psa - 12-03-05 21:18
----------------------------------------------------------------------
> 1. Please make a unified diff against the latest ALSA version.
Ok. Which is latest, alsa-1.0.10 or kernel-2.6.14.2? These diffs are
against 1.0.10. (Diffs are on two diffent files since they are not
technicly dependent on each outher.)
> 2. Note that the SPDIF output is supposed to be "spdif" PCM. If this PCM
is
> selected, the dxs 3 is selected automagically. Output to SPDIF though
the
> default PCM is a side-effect, and not guaranteed to work always.
There is no separate PCM format such as "spdif" PCM (unless you mean PCM
encapsulated in accordance of IEC958 Consumer encapsulation and electric
specs in spdif transmitter for the spdif cable, which has nothing to do
with this discussion). What is used in these ordinary consumer audio
products is raw (mono or stereo or prologic) 'Linear PCM' (other formats
like A-law are used for cordless connections, like phone). There is no
such basis for restricting the AC-link slot for spdif output to slot 10/11
(dxs3) only. On the contrary that would be against the AC97 specs.
>From AC97 2.3 specs:
There are two principal sources of audio data to consider:
· "Mixed" data originating from the OS mixer service. This data is
typically
stereo PCM format and passed on AC-link slots 3&4. Requirement
5.10.1.1
below ensures 48 kHz OS mixer output on AC-link slots 3&4 can be
routed to
both DAC and S/PDIF transmitter. Option 5.10.2.1 below expands
support to
8-48 kHz OS mixer output.
· "Pass-thru" data originating from an "independent S/PDIF
source". This
data can be PCM, AC-3**, MPEG, DTS, or other format, and is
typically
passed on AC-link slots 7&8 in 2-ch systems, AC-link slots 6&9 in
4-ch
systems, and AC-link slots 10&11 in 6-ch systems. The sample rate of
"independent S/PDIF source" data passed across AC-link must match
the
programmed SPSR (typically 48 kHz). Requirements 5.10.1.21 through
5.10.1.4 ensure availability of independent AC-link slot allocation
for
"pass-thru" data.
And further concerning register MX2A:
Bits D5-D4, SPSA[1:0], are read/write bits that control the S/PDIF
AC-link
Slot Assignment. Support for slots 3&4, 7&8, and 6&9 is required, and
10&11 is
also recommended.
So, as you can see, opposite to what you said, 3/4 (dxs0) must work, 10/11
(dxs3) is optional. If ALSA specs limit spdif dxs:s then ALSA is not AC97
compatible.
Also from practical point of view, typical linux audio software has no way
to select dxs (and no need or reason either) in case it uses only standard
stereo (or prologic) PCM. Nor is there such basis, need or reason for ALSA
library. It is really for the user trough mixer software to control
whether he wants to listen it trough analog or digital interface (or both,
as you can find from the AC97 spec). E.g without the above fixes I can't
listen to my internet radio (only spdif connected to the amplifier; and if
I put it trough the codec's analog mixer I loose prologic).
BTW. in ALC850 10/11 is also directed to the DAC for the back rear
surround channles (there is currently in ALSA no support for 8 channels
though).
> 3. It's wrong to toggle AC97 register bit in spdif_put callback. It
conflicts > with "IEC958 Playback Switch".
Now you lost me there. The (dxs3)_spdif_put() is the very put-function for
"IEC958 Playback Switch". Where is the contradiction?
There must be a way to enable spdif output even if there is no user audio
program running. E.g without that fix I can't hear my Mic in my speakers.
> 4. "IEC958 Analog Playback" is nonsense. It's identical with "Capture
Source"
> control.
Yes, as I said, it is identical from technical poit of view, but not from
conceptual point of view. For an ordinary user it is difficult to
understand that he has to change recording settings in order to hear from
the speakers what he wants. Techies have tendency to make user interfaces
purely from technical point of view, but user point of view must also be
accorded. Here (in case the of spdif output) the user point of view is
that this is a playback setting, thus it should appear in mixer as such.
E.g. in alsamixer "Playback" and "Capture" are on separate pages.
It could be argued that this feature should be in the user space mixer
software, not in driver mixer software. However in current ALSA
architechture only driver can know whether this control is relevant with
the codec chip in question.
> 5. It's correct to restrict the output sample rates to
> chip->ac97->rates[AC97_RATES_SPDIF] because the IEC958 itself supports
only
> limited sample rates (regardless what source you use).
There are no changes to the code in the diffs in this respect. The "FIXME"
comment I admid is not very clear. However there are reasons for it. It is
a reminder of following things.
In many codec chips it is possible to direct spdif input directly to spdif
output (like ALC850). In that case AC-link input sample rate is of no
relevance, it is the spdif input sample rate that should be restricted.
This is also connected to a larger issue of sample rates in an audio
system. AC97 (2.2/2.3) spec is very vague in this. It allows SRC:s in all
possible places. There can be SRC:s in both the controller and the codec
chip. So there can be SRC(s) in between the CPU and AC-link, there can be
an SRC in between the AC-link and the DAC, in between the AC-link and
spdif transmitter, in between the ADC and AC-link, in between the ADC and
spdif transmitter, etc. It's a real mess.
So, e.g. it could be the is an automatic SRC in between AC-link and spdif
output but not in betbeen ADC and spdif output, making above rate control
much more complex.
Eventually ALSA should accomodate all those combinations. "FIXME" is
really a reminder of that.
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
12-03-05 19:07 psa File Added: via82xx.c.udiff
12-03-05 19:08 psa File Added: ac97_patch.c.udiff
12-03-05 21:18 psa Note Added: 0006903
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-05 11:02 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-05 11:02 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-05-2005 12:02 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
psa - 12-03-05 21:18
----------------------------------------------------------------------
> 1. Please make a unified diff against the latest ALSA version.
Ok. Which is latest, alsa-1.0.10 or kernel-2.6.14.2? These diffs are
against 1.0.10. (Diffs are on two diffent files since they are not
technicly dependent on each outher.)
> 2. Note that the SPDIF output is supposed to be "spdif" PCM. If this PCM
is
> selected, the dxs 3 is selected automagically. Output to SPDIF though
the
> default PCM is a side-effect, and not guaranteed to work always.
There is no separate PCM format such as "spdif" PCM (unless you mean PCM
encapsulated in accordance of IEC958 Consumer encapsulation and electric
specs in spdif transmitter for the spdif cable, which has nothing to do
with this discussion). What is used in these ordinary consumer audio
products is raw (mono or stereo or prologic) 'Linear PCM' (other formats
like A-law are used for cordless connections, like phone). There is no
such basis for restricting the AC-link slot for spdif output to slot 10/11
(dxs3) only. On the contrary that would be against the AC97 specs.
>From AC97 2.3 specs:
There are two principal sources of audio data to consider:
· "Mixed" data originating from the OS mixer service. This data is
typically
stereo PCM format and passed on AC-link slots 3&4. Requirement
5.10.1.1
below ensures 48 kHz OS mixer output on AC-link slots 3&4 can be
routed to
both DAC and S/PDIF transmitter. Option 5.10.2.1 below expands
support to
8-48 kHz OS mixer output.
· "Pass-thru" data originating from an "independent S/PDIF
source". This
data can be PCM, AC-3**, MPEG, DTS, or other format, and is
typically
passed on AC-link slots 7&8 in 2-ch systems, AC-link slots 6&9 in
4-ch
systems, and AC-link slots 10&11 in 6-ch systems. The sample rate of
"independent S/PDIF source" data passed across AC-link must match
the
programmed SPSR (typically 48 kHz). Requirements 5.10.1.21 through
5.10.1.4 ensure availability of independent AC-link slot allocation
for
"pass-thru" data.
And further concerning register MX2A:
Bits D5-D4, SPSA[1:0], are read/write bits that control the S/PDIF
AC-link
Slot Assignment. Support for slots 3&4, 7&8, and 6&9 is required, and
10&11 is
also recommended.
So, as you can see, opposite to what you said, 3/4 (dxs0) must work, 10/11
(dxs3) is optional. If ALSA specs limit spdif dxs:s then ALSA is not AC97
compatible.
Also from practical point of view, typical linux audio software has no way
to select dxs (and no need or reason either) in case it uses only standard
stereo (or prologic) PCM. Nor is there such basis, need or reason for ALSA
library. It is really for the user trough mixer software to control
whether he wants to listen it trough analog or digital interface (or both,
as you can find from the AC97 spec). E.g without the above fixes I can't
listen to my internet radio (only spdif connected to the amplifier; and if
I put it trough the codec's analog mixer I loose prologic).
BTW. in ALC850 10/11 is also directed to the DAC for the back rear
surround channles (there is currently in ALSA no support for 8 channels
though).
> 3. It's wrong to toggle AC97 register bit in spdif_put callback. It
conflicts > with "IEC958 Playback Switch".
Now you lost me there. The (dxs3)_spdif_put() is the very put-function for
"IEC958 Playback Switch". Where is the contradiction?
There must be a way to enable spdif output even if there is no user audio
program running. E.g without that fix I can't hear my Mic in my speakers.
> 4. "IEC958 Analog Playback" is nonsense. It's identical with "Capture
Source"
> control.
Yes, as I said, it is identical from technical poit of view, but not from
conceptual point of view. For an ordinary user it is difficult to
understand that he has to change recording settings in order to hear from
the speakers what he wants. Techies have tendency to make user interfaces
purely from technical point of view, but user point of view must also be
accorded. Here (in case the of spdif output) the user point of view is
that this is a playback setting, thus it should appear in mixer as such.
E.g. in alsamixer "Playback" and "Capture" are on separate pages.
It could be argued that this feature should be in the user space mixer
software, not in driver mixer software. However in current ALSA
architechture only driver can know whether this control is relevant with
the codec chip in question.
> 5. It's correct to restrict the output sample rates to
> chip->ac97->rates[AC97_RATES_SPDIF] because the IEC958 itself supports
only
> limited sample rates (regardless what source you use).
There are no changes to the code in the diffs in this respect. The "FIXME"
comment I admid is not very clear. However there are reasons for it. It is
a reminder of following things.
In many codec chips it is possible to direct spdif input directly to spdif
output (like ALC850). In that case AC-link input sample rate is of no
relevance, it is the spdif input sample rate that should be restricted.
This is also connected to a larger issue of sample rates in an audio
system. AC97 (2.2/2.3) spec is very vague in this. It allows SRC:s in all
possible places. There can be SRC:s in both the controller and the codec
chip. So there can be SRC(s) in between the CPU and AC-link, there can be
an SRC in between the AC-link and the DAC, in between the AC-link and
spdif transmitter, in between the ADC and AC-link, in between the ADC and
spdif transmitter, etc. It's a real mess.
So, e.g. it could be the is an automatic SRC in between AC-link and spdif
output but not in betbeen ADC and spdif output, making above rate control
much more complex.
Eventually ALSA should accomodate all those combinations. "FIXME" is
really a reminder of that.
----------------------------------------------------------------------
tiwai - 12-05-05 12:02
----------------------------------------------------------------------
-> 1: The latest version is ALSA CVS tree.
-> 2: It's PCM name from ALSA point of view, i.e. the string argument to
be used in snd_pcm_open(). There are some standard names like "default",
"spdif", "surround51". The apps are supposed to use these standard names
as much as possible. In the case of via82xx, "spdif" PCM is provided to
choose DXS3.
-> 3: "IEC958 Playback Switch" is created in ac97_codec.c while "IEC958
Output Switch" is created in via82xx.c. I know it doesn't make much sense
to have both, though.
-> 4: But still you shouldn't have multiple controls for the very same
thing. They conflict with each other. What if happens if you change one
of them while you keep setting a different value to another? It's a
race.
-> 5: I see these reasons. But, as long as the IEC958 status bits on ac97
codec doesn't accept the specified sample rates, we can't use other
rates...
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
12-03-05 19:07 psa File Added: via82xx.c.udiff
12-03-05 19:08 psa File Added: ac97_patch.c.udiff
12-03-05 21:18 psa Note Added: 0006903
12-05-05 12:02 tiwai Note Added: 0006910
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-05 20:15 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-05 20:15 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-05-2005 21:15 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
tiwai - 12-05-05 12:02
----------------------------------------------------------------------
-> 1: The latest version is ALSA CVS tree.
-> 2: It's PCM name from ALSA point of view, i.e. the string argument to
be used in snd_pcm_open(). There are some standard names like "default",
"spdif", "surround51". The apps are supposed to use these standard names
as much as possible. In the case of via82xx, "spdif" PCM is provided to
choose DXS3.
-> 3: "IEC958 Playback Switch" is created in ac97_codec.c while "IEC958
Output Switch" is created in via82xx.c. I know it doesn't make much sense
to have both, though.
-> 4: But still you shouldn't have multiple controls for the very same
thing. They conflict with each other. What if happens if you change one
of them while you keep setting a different value to another? It's a
race.
-> 5: I see these reasons. But, as long as the IEC958 status bits on ac97
codec doesn't accept the specified sample rates, we can't use other
rates...
----------------------------------------------------------------------
psa - 12-05-05 21:15
----------------------------------------------------------------------
-> 1: The latest version is ALSA CVS tree.
Ok, will use it.
-> 2: It's PCM name from ALSA point of view, i.e. the string argument to
be
-> used in snd_pcm_open(). There are some standard names like "default",
-> "spdif", "surround51". The apps are supposed to use these standard
names as
-> much as possible. In the case of via82xx, "spdif" PCM is provided to
choose
-> DXS3.
What do they mean conceptually? ALSA Documentation is not exactly helpfull
here.
They seem to be mutually incompatible: "spdif" refers to playback route,
not to the type of content, whereas "surround51" refers to the type of
content, not neccessarily to the route. As can be seen from the AC97
specs, in case the codec chip has spdif output, it must provide posibility
to play back PCM simultaneusly through mixer and spdif. The software is
not suppose to make such choices, it is the 'human user' via a mixer. Ac97
2.3:
All S/PDIF capable Primary Codecs must be configurable to accept 48 kHz
PCM
data on AC-link slots 3&4 for DA conversion and concurrent S/PDIF
transmission.
So statement 'SPDIF output is supposed to be "spdif" PCM' is not correct
if it implies that 'PCM output is supposed to go to SPDIF output only if
software specifies directly or indirectly spdif and/or dxs3'. It might be
correct to say that '"spdif" PCM is supposed to go to SPDIF output through
dxs3, "default" stereo PCM is supposed to go through dxs0, depending mixer
settings, to DAC and/or SPDIF output'. Could we agree on this?
-> 3: "IEC958 Playback Switch" is created in ac97_codec.c while "IEC958
Output
-> Switch" is created in via82xx.c. I know it doesn't make much sense to
have
-> both, though.
Ok, you're right there. I wasn't aware of the two switches. In the mixer I
could see only "IEC958 Output Switch". In ac97_patch.c ALC655(850)-code
there is a selector called "IEC958 Playback Route". For reasons I have had
no time to study, the mixer code (both amixer and alsamixer) ignores the
"Route" part (I assume it has reserved meaning in the mixer code like
"Switch"). So mixer took this selector as "IEC958 Playback" and
disrecarded the "IEC958 Playback Switch".
Once I changed "IEC958 Playback Route" to "IEC958 Playback Source", which
is better name anyway, I could see both switches in the mixer. So that
takes some of my complaints away. I can manually enable spdif output
recardless the slot (dxs). I can make my internet radio and mic to work.
The diff:
-----------------------------------------------------------------
org ac97_patch.c
--- ac97_patch.c.myorg 2005-12-05 18:09:49.000000000 +0200
+++ ac97_patch.c 2005-12-05 18:12:45.000000000 +0200
@@ -2116,7 +2116,7 @@
/* AC97_PAGE_SINGLE("IEC958 Input Monitor", AC97_ALC650_MULTICH,
14, 1, 0, 0), */
{
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
- .name = SNDRV_CTL_NAME_IEC958("",PLAYBACK,NONE)
"Route",
+ .name = SNDRV_CTL_NAME_IEC958("",PLAYBACK,NONE)
"Source",
.info = alc655_iec958_route_info,
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
--------------------------------------------------------------------------
Is there any reason not to change the name? If not this fixes an obvius
bug.
However the real question now, as you pointed out, is the two similar
switches. I don't have VT8237(R) Datasheet available, but it seems that
the purpose of the "IEC958 Output Switch" (besides toggling spdif_on) is
to enable/disable spdif in a VIA-register. In my enviroment that seems to
have no effect whatsoever (whether using slot 3/4 or 10/11, PCM or AC3).
What is it supposed to do? And shouldn't it rather be the "IEC958 Playback
Switch" that toggles spdif_on?
If these both switches are really needed, it is somewhat a challange to
ALSA achitechture. There is no natural connection between the controller
chip code (via82xx.c in this case) and codec chip code (e.e. ALC850).
In any case again from "human mixer user" point of view there should be
only one switch to take care of both the VIA-settings and AC97 codec
settings for enabling/disabling spdif. A way to code it should be figured
out. Can we agree on this?
-> 4: But still you shouldn't have multiple controls for the very same
thing.
-> They conflict with each other. What if happens if you change one of
them
-> while you keep setting a different value to another? It's a race.
Yes, there is no protection against such race in the code (except: on AC97
codec register level there are appropriate locks). But same problem arises
if e.g. two user level mixer softwares are setting the same switch at the
same time. Actually in some AC97 code lock's are used (e.g. in
snd_ac97_put_spsa()). up()s and down()s could/should be added if needed.
There is an other thing though. If I change value in Capture page also the
new selector on the Playback page changes, but not the other way round. I
will look if there is a way to remove this problem.
-> 5: I see these reasons. But, as long as the IEC958 status bits on ac97
codec
-> doesn't accept the specified sample rates, we can't use other rates...
In current code yes. But code could be enhanced there: E.g. assume we have
hardware where AC-link/DAC supports 44.1/48 kHz, DAC and ADC have
independent rates, spdif transmitter supports only 48 kHz (MX3A,
rates[AC97_RATES_SPDIF]). Then following is possible: internal analog
mixer is connected to ADC, ADC is connected to spdif tramsmitter, ADC is
set to 48, but AC-link/DAC is still set to 44.1. Totally leagal and
functioning setup (enabling listening CD:s without software up-sampling
trough 48 kHz spdif). But current code does not support it. In reality the
hw.rate is not univalued concept. In above exsample there would be no
reason to limit the AC-link/DAC rate to 48 kHz as current code does. (This
discussion does not actually belong at all under this title, but is
completely different discussion on the potential further development of
the AC97 driver.)
No new diff attached till above issues are cleared.
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
12-03-05 19:07 psa File Added: via82xx.c.udiff
12-03-05 19:08 psa File Added: ac97_patch.c.udiff
12-03-05 21:18 psa Note Added: 0006903
12-05-05 12:02 tiwai Note Added: 0006910
12-05-05 21:15 psa Note Added: 0006916
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-05 20:45 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-05 20:45 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-05-2005 21:45 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
psa - 12-05-05 21:15
----------------------------------------------------------------------
-> 1: The latest version is ALSA CVS tree.
Ok, will use it.
-> 2: It's PCM name from ALSA point of view, i.e. the string argument to
be
-> used in snd_pcm_open(). There are some standard names like "default",
-> "spdif", "surround51". The apps are supposed to use these standard
names as
-> much as possible. In the case of via82xx, "spdif" PCM is provided to
choose
-> DXS3.
What do they mean conceptually? ALSA Documentation is not exactly helpfull
here.
They seem to be mutually incompatible: "spdif" refers to playback route,
not to the type of content, whereas "surround51" refers to the type of
content, not neccessarily to the route. As can be seen from the AC97
specs, in case the codec chip has spdif output, it must provide posibility
to play back PCM simultaneusly through mixer and spdif. The software is
not suppose to make such choices, it is the 'human user' via a mixer. Ac97
2.3:
All S/PDIF capable Primary Codecs must be configurable to accept 48 kHz
PCM
data on AC-link slots 3&4 for DA conversion and concurrent S/PDIF
transmission.
So statement 'SPDIF output is supposed to be "spdif" PCM' is not correct
if it implies that 'PCM output is supposed to go to SPDIF output only if
software specifies directly or indirectly spdif and/or dxs3'. It might be
correct to say that '"spdif" PCM is supposed to go to SPDIF output through
dxs3, "default" stereo PCM is supposed to go through dxs0, depending mixer
settings, to DAC and/or SPDIF output'. Could we agree on this?
-> 3: "IEC958 Playback Switch" is created in ac97_codec.c while "IEC958
Output
-> Switch" is created in via82xx.c. I know it doesn't make much sense to
have
-> both, though.
Ok, you're right there. I wasn't aware of the two switches. In the mixer I
could see only "IEC958 Output Switch". In ac97_patch.c ALC655(850)-code
there is a selector called "IEC958 Playback Route". For reasons I have had
no time to study, the mixer code (both amixer and alsamixer) ignores the
"Route" part (I assume it has reserved meaning in the mixer code like
"Switch"). So mixer took this selector as "IEC958 Playback" and
disrecarded the "IEC958 Playback Switch".
Once I changed "IEC958 Playback Route" to "IEC958 Playback Source", which
is better name anyway, I could see both switches in the mixer. So that
takes some of my complaints away. I can manually enable spdif output
recardless the slot (dxs). I can make my internet radio and mic to work.
The diff:
-----------------------------------------------------------------
org ac97_patch.c
--- ac97_patch.c.myorg 2005-12-05 18:09:49.000000000 +0200
+++ ac97_patch.c 2005-12-05 18:12:45.000000000 +0200
@@ -2116,7 +2116,7 @@
/* AC97_PAGE_SINGLE("IEC958 Input Monitor", AC97_ALC650_MULTICH,
14, 1, 0, 0), */
{
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
- .name = SNDRV_CTL_NAME_IEC958("",PLAYBACK,NONE)
"Route",
+ .name = SNDRV_CTL_NAME_IEC958("",PLAYBACK,NONE)
"Source",
.info = alc655_iec958_route_info,
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
--------------------------------------------------------------------------
Is there any reason not to change the name? If not this fixes an obvius
bug.
However the real question now, as you pointed out, is the two similar
switches. I don't have VT8237(R) Datasheet available, but it seems that
the purpose of the "IEC958 Output Switch" (besides toggling spdif_on) is
to enable/disable spdif in a VIA-register. In my enviroment that seems to
have no effect whatsoever (whether using slot 3/4 or 10/11, PCM or AC3).
What is it supposed to do? And shouldn't it rather be the "IEC958 Playback
Switch" that toggles spdif_on?
If these both switches are really needed, it is somewhat a challange to
ALSA achitechture. There is no natural connection between the controller
chip code (via82xx.c in this case) and codec chip code (e.e. ALC850).
In any case again from "human mixer user" point of view there should be
only one switch to take care of both the VIA-settings and AC97 codec
settings for enabling/disabling spdif. A way to code it should be figured
out. Can we agree on this?
-> 4: But still you shouldn't have multiple controls for the very same
thing.
-> They conflict with each other. What if happens if you change one of
them
-> while you keep setting a different value to another? It's a race.
Yes, there is no protection against such race in the code (except: on AC97
codec register level there are appropriate locks). But same problem arises
if e.g. two user level mixer softwares are setting the same switch at the
same time. Actually in some AC97 code lock's are used (e.g. in
snd_ac97_put_spsa()). up()s and down()s could/should be added if needed.
There is an other thing though. If I change value in Capture page also the
new selector on the Playback page changes, but not the other way round. I
will look if there is a way to remove this problem.
-> 5: I see these reasons. But, as long as the IEC958 status bits on ac97
codec
-> doesn't accept the specified sample rates, we can't use other rates...
In current code yes. But code could be enhanced there: E.g. assume we have
hardware where AC-link/DAC supports 44.1/48 kHz, DAC and ADC have
independent rates, spdif transmitter supports only 48 kHz (MX3A,
rates[AC97_RATES_SPDIF]). Then following is possible: internal analog
mixer is connected to ADC, ADC is connected to spdif tramsmitter, ADC is
set to 48, but AC-link/DAC is still set to 44.1. Totally leagal and
functioning setup (enabling listening CD:s without software up-sampling
trough 48 kHz spdif). But current code does not support it. In reality the
hw.rate is not univalued concept. In above exsample there would be no
reason to limit the AC-link/DAC rate to 48 kHz as current code does. (This
discussion does not actually belong at all under this title, but is
completely different discussion on the potential further development of
the AC97 driver.)
No new diff attached till above issues are cleared.
----------------------------------------------------------------------
tiwai - 12-05-05 21:45
----------------------------------------------------------------------
-> 2: The ALSA PCM name refers to both the route and its content.
For example, "spdif" means the SPDIF I/O and its accepted h/w
configuration (e.g. format, channels - in most cases S16, 2 channel).
Ditto for "surround51". It refers to the 5.1 output and its accepted h/w
format. So, it's not conceptually mutual.
It's software who determines the output to use, indeed, from the system
viewpoint. We can make the arbitrary output and change the output route
dynamically, but it's a different question. This is not what the kernel
driver code is involved. That is, your approach isn't a good solution.
-> 3: Yes, "IEC958 Playback Route" was fixed right now incidentally by
another patch :)
-> 4: Your patch doesn't provide the proper notification to multiple
controls, so the race occurs very easily on a single app. As said, having
two identical controls with different names is simply bad. Please don't.
-> 5: I don't understand your statement. If the codec chip can't set the
proper IEC958 status bits for the given sample rate, you can't use it.
(And, if ADC is linked to SPDIF, why bother to change the PCM code?)
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
12-03-05 19:07 psa File Added: via82xx.c.udiff
12-03-05 19:08 psa File Added: ac97_patch.c.udiff
12-03-05 21:18 psa Note Added: 0006903
12-05-05 12:02 tiwai Note Added: 0006910
12-05-05 21:15 psa Note Added: 0006916
12-05-05 21:45 tiwai Note Added: 0006917
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-06 2:28 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-06 2:28 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-06-2005 03:28 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
tiwai - 12-05-05 21:45
----------------------------------------------------------------------
-> 2: The ALSA PCM name refers to both the route and its content.
For example, "spdif" means the SPDIF I/O and its accepted h/w
configuration (e.g. format, channels - in most cases S16, 2 channel).
Ditto for "surround51". It refers to the 5.1 output and its accepted h/w
format. So, it's not conceptually mutual.
It's software who determines the output to use, indeed, from the system
viewpoint. We can make the arbitrary output and change the output route
dynamically, but it's a different question. This is not what the kernel
driver code is involved. That is, your approach isn't a good solution.
-> 3: Yes, "IEC958 Playback Route" was fixed right now incidentally by
another patch :)
-> 4: Your patch doesn't provide the proper notification to multiple
controls, so the race occurs very easily on a single app. As said, having
two identical controls with different names is simply bad. Please don't.
-> 5: I don't understand your statement. If the codec chip can't set the
proper IEC958 status bits for the given sample rate, you can't use it.
(And, if ADC is linked to SPDIF, why bother to change the PCM code?)
----------------------------------------------------------------------
psa - 12-06-05 03:28
----------------------------------------------------------------------
> 2: The ALSA PCM name refers to both the route and its content.
> For example, "spdif" means the SPDIF I/O and its accepted h/w
configuration
> (e.g. format, channels - in most cases S16, 2 channel). Ditto for
> "surround51". It refers to the 5.1 output and its accepted h/w format.
So,
> it's not conceptually mutual.
Aren't you hard headed. Now tell me please from where do get your
argument. By whos definition SPDIF implies format or slot? It implies only
route, nothing else. Havn't you read the AC97 specs or IEC958 specs? It is
really the contrary to what you say: PCM implies format, SPDIF does not;
it allows all kind of formats and contents; it's just a carrier. As to the
"surround51", it is quite ambiguous as well. It implies content but not
format. It can be 6 channel (3 * PCM slot), AC3 or DTS at least. But since
that call is snd_pcm_open() I assume it means 3 * PCM. How do you open AC3
stream? I can well see that it must be determined befor the driver whether
to use software AC3-decoder or put it trough as such to driver. But even
if it is put to driver it does not yet imply SPDIF. There could be a
hardware decoder on the controller or codec chip (not AC97 though). Then
again it would be the driver to determine what to do with the stream.
There again it would make sense to have a mixer switch to let the human
user to determine final destination.
In my opinion it is for sound producing software to determine the final
output only if the format and content allows no alternatives or if the
software has a human interface to set it. Other wise it must be left to
the mixer. Standard PCM allows alternatives, so why not to leave it to
mixer to route?
> It's software who determines the output to use, indeed, from the system
> viewpoint. We can make the arbitrary output and change the output route
> dynamically, but it's a different question. This is not what the kernel
driver > code is involved. That is, your approach isn't a good solution.
If it is for sound producing software to determine the final destination
of its product, then what are the mixer software for? Indeed what do you
think there are any sound mixers in the world, if not for 'the arbitrary
output and change the output route dynamically'. And if that is not what
the kernel driver code is involved with, then how can the mixer inside the
codec chip be controlled by the user. Isn't the alsamixer there exactly
for doing that trough kernel driver.
Are you really saying, that you have decided, that it is wrong to listen
arbitary sound program, that produces standard stereo PCM, trough my
amplifier that is connected to my computer by SPDIF-cable, even though it
works in practice and comforms with AC97 specs? And how would it
contradict the driver design? It seems to me that the driver and controls
there are designed exactly for that. If not, for what? And what is the
alsamixer for? I would hate to extend this discussion to more complex
mixers (like SB Live!) that has several SPDIF inputs and outputs (and
other inputs and outputs of all kinds). How on earth could the sound
producing software know where the sound is supposed to end up. It would be
possible only if there would be fully fledged mixer as part of every sound
producing software.
Conceptually mixer is a device that can take input (in this case sound
input) from various different sources in various formats as the human user
determines mix them together and route them (and maybe translate their
format) to various output connectors in various formats as determined by
human user. Why pretend that there isn't such capability (albeit limited)
in the hardware (that's what the harware designer has intended it for).
If you have not decided that it is wrong to listen simple internet radio
program or simple CD-player program, that has not a comprehensive mixer as
part of it, trough a spdif cable, then what is your sollution?
-> 4: Your patch doesn't provide the proper notification to multiple
controls,
-> so the race occurs very easily on a single app. As said, having two
-> identical controls with different names is simply bad. Please don't.
Ok, mayby it's bad. But then other sollution must be found. I just wonder
why the notification goes only one way. The code for both in the driver is
exactly the same. Only difference is the name: "Capture Source" vs.
"Playback Analog Source". It must be in the actual alsamixer code since
the latter control appears as standard two channel enum control while the
former has special format of display. My guess is, the capture side code
of the mixer does not react to notification since it has different name,
while the standard enum code somehow recognizes that this is really same
control just with different name.
Any way alternate sollution would be to change alsamixer code. But how
could it know if the codec chip has this capability?
-> 5: I don't understand your statement. If the codec chip can't set the
proper
-> IEC958 status bits for the given sample rate, you can't use it. (And,
if ADC
-> is linked to SPDIF, why bother to change the PCM code?)
Ah, now I get it. Are you talking about the 'Validity bits' in MAX2A and
MX3A? It would be a good idea to use them. But current code does not.
Instead it just puts max and min valus for hw.rate inside
snd_pcm_limit_hw_rates(). No checking of validity bits, at least not
here.
if (chip->spdif_on && viadev->reg_offset == 0x30) {
/* DXS#3 and spdif is on */
runtime->hw.rates = chip->ac97->rates[AC97_RATES_SPDIF];
snd_pcm_limit_hw_rates(runtime);
The exsample situation I was descriping would not require setting limits
to AC-link/DAC rate, as this code does. I.e code does not allow
AC-link/DAC run 44.1 and ADC/SPDIF-transmitter 48, but forces both to run
48.
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
12-03-05 19:07 psa File Added: via82xx.c.udiff
12-03-05 19:08 psa File Added: ac97_patch.c.udiff
12-03-05 21:18 psa Note Added: 0006903
12-05-05 12:02 tiwai Note Added: 0006910
12-05-05 21:15 psa Note Added: 0006916
12-05-05 21:45 tiwai Note Added: 0006917
12-06-05 03:28 psa Note Added: 0006919
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-07 14:56 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-07 14:56 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-07-2005 15:56 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
psa - 12-06-05 03:28
----------------------------------------------------------------------
> 2: The ALSA PCM name refers to both the route and its content.
> For example, "spdif" means the SPDIF I/O and its accepted h/w
configuration
> (e.g. format, channels - in most cases S16, 2 channel). Ditto for
> "surround51". It refers to the 5.1 output and its accepted h/w format.
So,
> it's not conceptually mutual.
Aren't you hard headed. Now tell me please from where do get your
argument. By whos definition SPDIF implies format or slot? It implies only
route, nothing else. Havn't you read the AC97 specs or IEC958 specs? It is
really the contrary to what you say: PCM implies format, SPDIF does not;
it allows all kind of formats and contents; it's just a carrier. As to the
"surround51", it is quite ambiguous as well. It implies content but not
format. It can be 6 channel (3 * PCM slot), AC3 or DTS at least. But since
that call is snd_pcm_open() I assume it means 3 * PCM. How do you open AC3
stream? I can well see that it must be determined befor the driver whether
to use software AC3-decoder or put it trough as such to driver. But even
if it is put to driver it does not yet imply SPDIF. There could be a
hardware decoder on the controller or codec chip (not AC97 though). Then
again it would be the driver to determine what to do with the stream.
There again it would make sense to have a mixer switch to let the human
user to determine final destination.
In my opinion it is for sound producing software to determine the final
output only if the format and content allows no alternatives or if the
software has a human interface to set it. Other wise it must be left to
the mixer. Standard PCM allows alternatives, so why not to leave it to
mixer to route?
> It's software who determines the output to use, indeed, from the system
> viewpoint. We can make the arbitrary output and change the output route
> dynamically, but it's a different question. This is not what the kernel
driver > code is involved. That is, your approach isn't a good solution.
If it is for sound producing software to determine the final destination
of its product, then what are the mixer software for? Indeed what do you
think there are any sound mixers in the world, if not for 'the arbitrary
output and change the output route dynamically'. And if that is not what
the kernel driver code is involved with, then how can the mixer inside the
codec chip be controlled by the user. Isn't the alsamixer there exactly
for doing that trough kernel driver.
Are you really saying, that you have decided, that it is wrong to listen
arbitary sound program, that produces standard stereo PCM, trough my
amplifier that is connected to my computer by SPDIF-cable, even though it
works in practice and comforms with AC97 specs? And how would it
contradict the driver design? It seems to me that the driver and controls
there are designed exactly for that. If not, for what? And what is the
alsamixer for? I would hate to extend this discussion to more complex
mixers (like SB Live!) that has several SPDIF inputs and outputs (and
other inputs and outputs of all kinds). How on earth could the sound
producing software know where the sound is supposed to end up. It would be
possible only if there would be fully fledged mixer as part of every sound
producing software.
Conceptually mixer is a device that can take input (in this case sound
input) from various different sources in various formats as the human user
determines mix them together and route them (and maybe translate their
format) to various output connectors in various formats as determined by
human user. Why pretend that there isn't such capability (albeit limited)
in the hardware (that's what the harware designer has intended it for).
If you have not decided that it is wrong to listen simple internet radio
program or simple CD-player program, that has not a comprehensive mixer as
part of it, trough a spdif cable, then what is your sollution?
-> 4: Your patch doesn't provide the proper notification to multiple
controls,
-> so the race occurs very easily on a single app. As said, having two
-> identical controls with different names is simply bad. Please don't.
Ok, mayby it's bad. But then other sollution must be found. I just wonder
why the notification goes only one way. The code for both in the driver is
exactly the same. Only difference is the name: "Capture Source" vs.
"Playback Analog Source". It must be in the actual alsamixer code since
the latter control appears as standard two channel enum control while the
former has special format of display. My guess is, the capture side code
of the mixer does not react to notification since it has different name,
while the standard enum code somehow recognizes that this is really same
control just with different name.
Any way alternate sollution would be to change alsamixer code. But how
could it know if the codec chip has this capability?
-> 5: I don't understand your statement. If the codec chip can't set the
proper
-> IEC958 status bits for the given sample rate, you can't use it. (And,
if ADC
-> is linked to SPDIF, why bother to change the PCM code?)
Ah, now I get it. Are you talking about the 'Validity bits' in MAX2A and
MX3A? It would be a good idea to use them. But current code does not.
Instead it just puts max and min valus for hw.rate inside
snd_pcm_limit_hw_rates(). No checking of validity bits, at least not
here.
if (chip->spdif_on && viadev->reg_offset == 0x30) {
/* DXS#3 and spdif is on */
runtime->hw.rates = chip->ac97->rates[AC97_RATES_SPDIF];
snd_pcm_limit_hw_rates(runtime);
The exsample situation I was descriping would not require setting limits
to AC-link/DAC rate, as this code does. I.e code does not allow
AC-link/DAC run 44.1 and ADC/SPDIF-transmitter 48, but forces both to run
48.
----------------------------------------------------------------------
tiwai - 12-07-05 15:56
----------------------------------------------------------------------
Please read my comment carefully before emotional reaction.
"spdif" PCM implies the I/O from/to SPDIF _and_ the formats accepted by
_hardware_. In your case, it's S16_LE 2channels. It's quite hardware
specific, not per SPDIF definition. Ditto for "surround51". It routes to
analog 5.1 outputs _and_ restricts the hardware configuration that the
hardware accepts. OK? (Also, I didn't mention about slots anywhere.)
It's fine to allow the SPDIF-output with the "default" PCM output. But,
it's not mandatory. Instead, "spdif" PCM assures to output to SPDIF even
with non-audio data. For the "default" PCM, usually the concurrent
access/mix is allowed, so it's not suitable for non-audio data.
About the mixer: You think obviously that the sound system consists of
only a kernel driver. No, we have a user-space layer to mangle many
things. The mixer is indeed a part of alsa-lib stuff.
About the SPDIF output sample rate: It's PRSR bits of register 3A.
You'll find that only limited sample rates are available for SPIDF out
with AC97 codecs.
Anyway, the further argument is pretty useless. Let's stop it. If you
want to continue, please post it to alsa-devel ML instead of the bug
report.
Now, let's revise the possible improvements.
For the SPDIF output on VIA823x, we have the following capabilities:
- DXS3 dedicated for SPDIF
The merit is that you can play still 3 DXS analog streams independently
without signal mix. That is, you can avoid dmix and still use SPDIF
safely even with non-audio data. The demerit is that DXS output is fixed
to 48kHz (it does SRC by itself). (So, basically, it's a bug to call
snd_ac97_set_rate(AC97_SPDIF) in snd_via8233_playback_rate. It has to be
fixed...)
We can set SPDIF slots 3&4 as default for the concurrent output, and
disable DXS3 unless the "spdif" PCM is opened. The slot assigment can be
then changed automatically to 10&11 when "spdif" PCM is opened (via
VIA8233.conf).
- Multi-channel stream for both analog and SPDIF with slot 3&4
The merit is that it allows you non-48k (32k and 44.1k), too. However,
multi-channel stream is exclusive. That is, no DXS is possible. In
addition, we'll need a mechanism to shut up the analog output
automatically in the case of non-audio data by checking the SPDIF status
bits.
To my eyes, the first one looks simplier.
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
12-03-05 19:07 psa File Added: via82xx.c.udiff
12-03-05 19:08 psa File Added: ac97_patch.c.udiff
12-03-05 21:18 psa Note Added: 0006903
12-05-05 12:02 tiwai Note Added: 0006910
12-05-05 21:15 psa Note Added: 0006916
12-05-05 21:45 tiwai Note Added: 0006917
12-06-05 03:28 psa Note Added: 0006919
12-07-05 15:56 tiwai Note Added: 0006943
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2005-12-08 23:15 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2005-12-08 23:15 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 12-09-2005 00:15 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
tiwai - 12-07-05 15:56
----------------------------------------------------------------------
Please read my comment carefully before emotional reaction.
"spdif" PCM implies the I/O from/to SPDIF _and_ the formats accepted by
_hardware_. In your case, it's S16_LE 2channels. It's quite hardware
specific, not per SPDIF definition. Ditto for "surround51". It routes to
analog 5.1 outputs _and_ restricts the hardware configuration that the
hardware accepts. OK? (Also, I didn't mention about slots anywhere.)
It's fine to allow the SPDIF-output with the "default" PCM output. But,
it's not mandatory. Instead, "spdif" PCM assures to output to SPDIF even
with non-audio data. For the "default" PCM, usually the concurrent
access/mix is allowed, so it's not suitable for non-audio data.
About the mixer: You think obviously that the sound system consists of
only a kernel driver. No, we have a user-space layer to mangle many
things. The mixer is indeed a part of alsa-lib stuff.
About the SPDIF output sample rate: It's PRSR bits of register 3A.
You'll find that only limited sample rates are available for SPIDF out
with AC97 codecs.
Anyway, the further argument is pretty useless. Let's stop it. If you
want to continue, please post it to alsa-devel ML instead of the bug
report.
Now, let's revise the possible improvements.
For the SPDIF output on VIA823x, we have the following capabilities:
- DXS3 dedicated for SPDIF
The merit is that you can play still 3 DXS analog streams independently
without signal mix. That is, you can avoid dmix and still use SPDIF
safely even with non-audio data. The demerit is that DXS output is fixed
to 48kHz (it does SRC by itself). (So, basically, it's a bug to call
snd_ac97_set_rate(AC97_SPDIF) in snd_via8233_playback_rate. It has to be
fixed...)
We can set SPDIF slots 3&4 as default for the concurrent output, and
disable DXS3 unless the "spdif" PCM is opened. The slot assigment can be
then changed automatically to 10&11 when "spdif" PCM is opened (via
VIA8233.conf).
- Multi-channel stream for both analog and SPDIF with slot 3&4
The merit is that it allows you non-48k (32k and 44.1k), too. However,
multi-channel stream is exclusive. That is, no DXS is possible. In
addition, we'll need a mechanism to shut up the analog output
automatically in the case of non-audio data by checking the SPDIF status
bits.
To my eyes, the first one looks simplier.
----------------------------------------------------------------------
psa - 12-09-05 00:15
----------------------------------------------------------------------
> Please read my comment carefully before emotional reaction.
Sorry if seemd emotional or personal!
> "spdif" PCM implies the I/O from/to SPDIF _and_ the formats accepted by
> _hardware_. In your case, it's S16_LE 2channels. It's quite hardware
specific,
> not per SPDIF definition. Ditto for "surround51". It routes to analog
5.1
> outputs _and_ restricts the hardware configuration that the hardware
accepts.
> OK? (Also, I didn't mention about slots anywhere.)
> It's fine to allow the SPDIF-output with the "default" PCM output. But,
it's
> not mandatory. Instead, "spdif" PCM assures to output to SPDIF even
with
> non-audio data. For the "default" PCM, usually the concurrent access/mix
is
> allowed, so it's not suitable for non-audio data.
Hm! So only situation for a software to use "spdif" would be when it's not
stuff suitable for a DAC. Is that correct? If so that's exactly what my
complaint was about: "spdif" is wrong name for this, because it does not
imply non-audio (I assume you mean non audio PCM), "nonaudio" would be
much better. Is "spdif" used with ac3? The point is that hardware might
have many other ways to deal with non-audio-PCM than spdif output (e.g
build in decoder).
> About the mixer: You think obviously that the sound system consists of
only a
> kernel driver. No, we have a user-space layer to mangle many things. The
mixer
> is indeed a part of alsa-lib stuff.
No! It would be nice though to have fully fledged software mixer that
would normally reside between any sound producing software and kernel.
However it should be optional systems setting. But as far I know that is
not currently part of ALSA architechture. Or is there such software? I
guess it would have two parts, controls inside the alsa-library that would
notify mixer (like alsamixer) the same way as driver, and the driver.
Still it would be silly not to use to the full the cababilities offered by
the hardware (through the driver) even in such a setting.
> About the SPDIF output sample rate: It's PRSR bits of register 3A.
You'll find
> that only limited sample rates are available for SPIDF out with AC97
codecs.
I assume you mean SPSR. That is the rate(s) accepted by spdif transmitter.
This is totally besides the poin I was making! I was suggesting using MX2A
VCFG, SPCV and MX3A 15:0.
> Anyway, the further argument is pretty useless. Let's stop it. If you
want to > continue, please post it to alsa-devel ML instead of the bug
report.
How do I do that? Can you answer by e-mail?
Point has not been to argue, but understand what you mean. Hopefully you
have tryed to understand what I mean.
> Now, let's revise the possible improvements.
> For the SPDIF output on VIA823x, we have the following capabilities:
> - DXS3 dedicated for SPDIF
> The merit is that you can play still 3 DXS analog streams
independently
> without signal mix. That is, you can avoid dmix and still use SPDIF
safely
> even with non-audio data. The demerit is that DXS output is fixed to
48kHz
> (it does SRC by itself). (So, basically, it's a bug to call
> snd_ac97_set_rate(AC97_SPDIF) in snd_via8233_playback_rate. It has to
be
> fixed...)
This is true up to 6 channel PCM, but not in 8 channel (supported by
ALC850).
> We can set SPDIF slots 3&4 as default for the concurrent output, and
disable > DXS3 unless the "spdif" PCM is opened. The slot assigment can be
then changed > automatically to 10&11 when "spdif" PCM is opened (via
VIA8233.conf).
Again must somehow accord 8 channel output where 10&11 is used for back
surround.
> - Multi-channel stream for both analog and SPDIF with slot 3&4
>
> The merit is that it allows you non-48k (32k and 44.1k), too. However,
> multi-channel stream is exclusive. That is, no DXS is possible. In
addition,
> we'll need a mechanism to shut up the analog output automatically in the
case
> of non-audio data by checking the SPDIF status bits.
Here I might be ignorant, but doesn't multi-channel mean using more than
one slot pair for more than two channels? And what I have understood of
the AC97 specs, rate can be set separately for each slot pair (provided
codec chip supports it). Why wouldn't it be possible to have let's say 6
channel audio through slots 3&4, 7&8, 6&9 with 44.1 to DACs, while putting
10&11 to spdif with 48. And as far as I understand you can put only one
slot pair to spdif transmitter. Though I have used for testing a setting
where in 6 channel mode surround channels were direceted to spdif (and
it's not totally unthinkable that in 4 channel mode analog output is used
for front speakers and spdif output for surround speakers ;-)
I guess here we hit the rate mess inherent in the AC97 specs. In that I
see two possible strategies:
1. when initializing the hardware, all the possible compinations mapped
somehow. This map is then used to limit what user can do whit
first-come-firs-seved pronciple.
2. Every time there is an attemted to change a rate or routing, it is
tested whether the resulting configutation is allowed. If not change is
denied.
Also I think the the ioctl should fail. Now it seems, if some change is
not allowed, it is just silently ignored.
This migh require quite total overhaul of the driver (at leat the AC97
part).
I migh be willing to look at it, and make some suggestions, if you so
want.
However if your first responce is going to be that what I'm suggesting is
all wrong (instead trying to find out what I mean in case it's unclear) I
won't bother.
> To my eyes, the first one looks simplier.
If choice must be made, I agree. Really what ever makes the two spdif
switches "Playback" and "Output" to merge in to one, and allow ordinary
PCM to be routed to spdif (with some rate control), is OK as far as I'm
concerned. That's what it has been all about from my point of view.
Basically: good defaults but maximal (sensible) freedom to human user.
It would be greatly appriciated if would answer my sincere questions (in
this and previous notes). They are there because I don't know the answers
(not to argue). I would help me to be more usefull.
This will be my last unsolicited note on this ID.
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
12-03-05 19:07 psa File Added: via82xx.c.udiff
12-03-05 19:08 psa File Added: ac97_patch.c.udiff
12-03-05 21:18 psa Note Added: 0006903
12-05-05 12:02 tiwai Note Added: 0006910
12-05-05 21:15 psa Note Added: 0006916
12-05-05 21:45 tiwai Note Added: 0006917
12-06-05 03:28 psa Note Added: 0006919
12-07-05 15:56 tiwai Note Added: 0006943
12-09-05 00:15 psa Note Added: 0006964
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850)
@ 2006-01-13 0:09 bugtrack
0 siblings, 0 replies; 10+ messages in thread
From: bugtrack @ 2006-01-13 0:09 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1611>
======================================================================
Reported By: psa
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1611
Category: PCI - via82xx
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 12-02-2005 16:49 CET
Last Modified: 01-13-2006 01:09 CET
======================================================================
Summary: PCM to spdif blocked(any AC95), mic to spdif (in
ALC650/655/850)
Description:
After transition 1.0.9b -> 1.0.10 PCM output (or 'Analig In', if ADC ->
spdif supported) can't be directed to spdif output. Caused by a feature
bug in via82xx-driver. Driver now enables spdif out only if IEC958
Playback AC97-SPSA dxs3 (slot 10/11 reserved for non PCM like ac3) is
selected. This is obviously done with the assumtion that if user program
wants to send something to spdif it uses dxs3 and/or with the assumption
that only non PCM strams can be directed to spdif port. However both of
these assumtions are too restrictive. Even further these assumprions
ignore the fact that several ac97 chips (like ALC650) can direct ADC
output (originaly intended for capture) to spdif output; and some chips
(e.g. ALC655/850) can direct spdif input directly to spdif output.
However many ordinary sound programs (like internet radio) have no control
on which dxs they direct their output. They put PCM (stereo or prologic)
to standard stereo output which is dxs0 (slot 3/4). In the other end of
the spdif cable there can be all kind of hardware, including amplifiers
that can take several formats including standard PCM. In makes perfect
sense to direct dxs0 to such spdif devices. Also since, although slots
have certain standard usages, user software is free to use them as they
wish, there is no reason to restrict the slot selection.
In addition dxs selection is of no relevance when spdif out signal is
taken from ADC or spdif input. Yet it should be possible to enable spdif
output.
The first restriction is implemented in the code in pci/via82xx.c in
snd_via8233_playback_prepare():
if (chip->spdif_on && viadev->reg_offset == 0x30)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
where reg_offset 0x30 is the offset of DXS3. snd_ac97_set_rate() again is
the place (only place as far as I can see) spdif output is enabled. The
second restriction is implemeted by the fact that 'IEC958 Output'-swicth
does not enable spdif output. It only sets '->spdif_on'. This all means
that spdif output is anabled only if user software is started with
spdif_on set (by 'IEC958 Output'-swicth). E.g can't do the following: Set
'Capture Source' select to Mic, redirect ADC (Analog In) to spdif output,
set 'IEC958 Output'-swicth (, select DXS0). Now you should here microphone
trouhg you external amplifier connected by spdif even if no software is
running. No can do.
Suggested fix:
The first restriction is simply removed by removin the second condition in
the if-statement:
if (chip->spdif_on)
snd_ac97_set_rate(chip->ac97, AC97_SPDIF, runtime->rate);
The second restriction is removed by adding to
snd_via8233_dxs3_spdif_put() enbaling/disabling spdif output.
In addition it suggested that in case ac97 chip supports directing ADC to
spdif output (like ALC650/655/850), in pci/ac97/ac97_patch.c in
appropriate *_patch a ADC source select is added on the playback side
(kind of duplicating 'Capture Source') since this select is used also to
select spdif output in case ADC is directed to spdif output, and is thus a
'playback'-mixer-control.
Diffs are included. Note that snd_via8233_dxs3_spdif_*:s have been changed
to snd_via8233_spdif_*:s since they are no more specific to dxs3. There is
also a diff for adding the mixer control descriped above for ALC850 as an
exsample.
In setting available for me everything seems to work fine above
restrictions removed.
via82xx diff enclosed.
ac97_patch diff:
-----------------------------------------------------------------------------
*** pci/ac97/ac97_patch.c.myorg Thu Nov 24 19:22:05 2005
--- pci/ac97/ac97_patch.c Sun Nov 27 23:22:48 2005
***************
*** 2106,2111 ****
--- 2106,2115 ----
0);
}
+ static const char *alc655_rec_sel[] = { "Mic", "CD", "Mute", "Aux",
"Line", "Mix", "Mono Mix", "Phone"};
+
+ static const struct ac97_enum alc655_enum =
AC97_ENUM_DOUBLE(AC97_REC_SEL, 8,
0, 8, alc655_rec_sel);
+
static const snd_kcontrol_new_t snd_ac97_spdif_controls_alc655[] = {
AC97_PAGE_SINGLE(SNDRV_CTL_NAME_IEC958("",CAPTURE,SWITCH),
AC97_ALC650_MULTICH, 11, 1, 0, 0),
/* disable this controls since it doesn't work as expected */
***************
*** 2117,2122 ****
--- 2121,2127 ----
.get = alc655_iec958_route_get,
.put = alc655_iec958_route_put,
},
+ AC97_ENUM(SNDRV_CTL_NAME_IEC958("Analog ",PLAYBACK,NONE),
alc655_enum),
};
static int patch_alc655_specific(ac97_t * ac97)
---------------------------------------------------------------------------
======================================================================
----------------------------------------------------------------------
psa - 12-09-05 00:15
----------------------------------------------------------------------
> Please read my comment carefully before emotional reaction.
Sorry if seemd emotional or personal!
> "spdif" PCM implies the I/O from/to SPDIF _and_ the formats accepted by
> _hardware_. In your case, it's S16_LE 2channels. It's quite hardware
specific,
> not per SPDIF definition. Ditto for "surround51". It routes to analog
5.1
> outputs _and_ restricts the hardware configuration that the hardware
accepts.
> OK? (Also, I didn't mention about slots anywhere.)
> It's fine to allow the SPDIF-output with the "default" PCM output. But,
it's
> not mandatory. Instead, "spdif" PCM assures to output to SPDIF even
with
> non-audio data. For the "default" PCM, usually the concurrent access/mix
is
> allowed, so it's not suitable for non-audio data.
Hm! So only situation for a software to use "spdif" would be when it's not
stuff suitable for a DAC. Is that correct? If so that's exactly what my
complaint was about: "spdif" is wrong name for this, because it does not
imply non-audio (I assume you mean non audio PCM), "nonaudio" would be
much better. Is "spdif" used with ac3? The point is that hardware might
have many other ways to deal with non-audio-PCM than spdif output (e.g
build in decoder).
> About the mixer: You think obviously that the sound system consists of
only a
> kernel driver. No, we have a user-space layer to mangle many things. The
mixer
> is indeed a part of alsa-lib stuff.
No! It would be nice though to have fully fledged software mixer that
would normally reside between any sound producing software and kernel.
However it should be optional systems setting. But as far I know that is
not currently part of ALSA architechture. Or is there such software? I
guess it would have two parts, controls inside the alsa-library that would
notify mixer (like alsamixer) the same way as driver, and the driver.
Still it would be silly not to use to the full the cababilities offered by
the hardware (through the driver) even in such a setting.
> About the SPDIF output sample rate: It's PRSR bits of register 3A.
You'll find
> that only limited sample rates are available for SPIDF out with AC97
codecs.
I assume you mean SPSR. That is the rate(s) accepted by spdif transmitter.
This is totally besides the poin I was making! I was suggesting using MX2A
VCFG, SPCV and MX3A 15:0.
> Anyway, the further argument is pretty useless. Let's stop it. If you
want to > continue, please post it to alsa-devel ML instead of the bug
report.
How do I do that? Can you answer by e-mail?
Point has not been to argue, but understand what you mean. Hopefully you
have tryed to understand what I mean.
> Now, let's revise the possible improvements.
> For the SPDIF output on VIA823x, we have the following capabilities:
> - DXS3 dedicated for SPDIF
> The merit is that you can play still 3 DXS analog streams
independently
> without signal mix. That is, you can avoid dmix and still use SPDIF
safely
> even with non-audio data. The demerit is that DXS output is fixed to
48kHz
> (it does SRC by itself). (So, basically, it's a bug to call
> snd_ac97_set_rate(AC97_SPDIF) in snd_via8233_playback_rate. It has to
be
> fixed...)
This is true up to 6 channel PCM, but not in 8 channel (supported by
ALC850).
> We can set SPDIF slots 3&4 as default for the concurrent output, and
disable > DXS3 unless the "spdif" PCM is opened. The slot assigment can be
then changed > automatically to 10&11 when "spdif" PCM is opened (via
VIA8233.conf).
Again must somehow accord 8 channel output where 10&11 is used for back
surround.
> - Multi-channel stream for both analog and SPDIF with slot 3&4
>
> The merit is that it allows you non-48k (32k and 44.1k), too. However,
> multi-channel stream is exclusive. That is, no DXS is possible. In
addition,
> we'll need a mechanism to shut up the analog output automatically in the
case
> of non-audio data by checking the SPDIF status bits.
Here I might be ignorant, but doesn't multi-channel mean using more than
one slot pair for more than two channels? And what I have understood of
the AC97 specs, rate can be set separately for each slot pair (provided
codec chip supports it). Why wouldn't it be possible to have let's say 6
channel audio through slots 3&4, 7&8, 6&9 with 44.1 to DACs, while putting
10&11 to spdif with 48. And as far as I understand you can put only one
slot pair to spdif transmitter. Though I have used for testing a setting
where in 6 channel mode surround channels were direceted to spdif (and
it's not totally unthinkable that in 4 channel mode analog output is used
for front speakers and spdif output for surround speakers ;-)
I guess here we hit the rate mess inherent in the AC97 specs. In that I
see two possible strategies:
1. when initializing the hardware, all the possible compinations mapped
somehow. This map is then used to limit what user can do whit
first-come-firs-seved pronciple.
2. Every time there is an attemted to change a rate or routing, it is
tested whether the resulting configutation is allowed. If not change is
denied.
Also I think the the ioctl should fail. Now it seems, if some change is
not allowed, it is just silently ignored.
This migh require quite total overhaul of the driver (at leat the AC97
part).
I migh be willing to look at it, and make some suggestions, if you so
want.
However if your first responce is going to be that what I'm suggesting is
all wrong (instead trying to find out what I mean in case it's unclear) I
won't bother.
> To my eyes, the first one looks simplier.
If choice must be made, I agree. Really what ever makes the two spdif
switches "Playback" and "Output" to merge in to one, and allow ordinary
PCM to be routed to spdif (with some rate control), is OK as far as I'm
concerned. That's what it has been all about from my point of view.
Basically: good defaults but maximal (sensible) freedom to human user.
It would be greatly appriciated if would answer my sincere questions (in
this and previous notes). They are there because I don't know the answers
(not to argue). I would help me to be more usefull.
This will be my last unsolicited note on this ID.
----------------------------------------------------------------------
rlrevell - 01-13-06 01:09
----------------------------------------------------------------------
What's the status of this, in 20 words or less? Is it a bug, or multiple
bugs, or what?
Issue History
Date Modified Username Field Change
======================================================================
12-02-05 16:49 psa New Issue
12-02-05 16:49 psa File Added: via82xx.c.diff
12-02-05 16:51 psa File Added: ac97_patch.c.diff
12-02-05 17:39 tiwai Note Added: 0006897
12-03-05 19:07 psa File Added: via82xx.c.udiff
12-03-05 19:08 psa File Added: ac97_patch.c.udiff
12-03-05 21:18 psa Note Added: 0006903
12-05-05 12:02 tiwai Note Added: 0006910
12-05-05 21:15 psa Note Added: 0006916
12-05-05 21:45 tiwai Note Added: 0006917
12-06-05 03:28 psa Note Added: 0006919
12-07-05 15:56 tiwai Note Added: 0006943
12-09-05 00:15 psa Note Added: 0006964
01-13-06 01:09 rlrevell Note Added: 0007611
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-01-13 0:09 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-06 2:28 [ALSA - driver 0001611]: PCM to spdif blocked(any AC95), mic to spdif (in ALC650/655/850) bugtrack
-- strict thread matches above, loose matches on Subject: below --
2006-01-13 0:09 bugtrack
2005-12-08 23:15 bugtrack
2005-12-07 14:56 bugtrack
2005-12-05 20:45 bugtrack
2005-12-05 20:15 bugtrack
2005-12-05 11:02 bugtrack
2005-12-03 20:18 bugtrack
2005-12-02 16:39 bugtrack
2005-12-02 15:49 bugtrack
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox