On Tue, Dec 22, 2009 at 04:39:11AM -0600, Chris Bennett wrote: > Jacob Meuser wrote: > >On Tue, Dec 22, 2009 at 12:43:02AM +0000, Jacob Meuser wrote: > >>On Mon, Dec 21, 2009 at 07:46:20AM -0600, Chris Bennett wrote: > > > >>>Now how do I get these channels out? > >>>I find the mixerctl output for this one, rather confusing > >>read azalia(4). > > > >you should read the manual, of course. the most important part of the > >manual is the part that explains the azalia architecture. this is > >important to understand for the mixer item names to make sense, since > >the mixer items represent widgets in the codec. > > > >oh, I forgot to explain a basic codec there. I explained all the > >parts but never really gave a "big picture". > > > >so here is an explanation of how playback works (should maybe find > >it's way into azalia(4)?), with examples using your mixerctl output > >(though I removed the "vendor" controls, since they are gone in > >-current). > > > >As exlained in the manual, dac widgets convert digital data to > >analog sound. In most cases, dacs get data from the host controller > >when an application write()s audio data to the device. The dacs > >convert the data to sound and that sound travels through the codec, > >eventually reaching a jack or some other endpoint widget. The path > >of the sound can be determined with the mixer controls that have the > >"source" property name. > > > >Output jacks cannot be source widgets, and therefore will always have > >a source property control. Also, dacs will always be a source for > >some widgets, otherwise there would be no way for the codec to play > >analog audio. Quite a bit of information about a codec can be > >obtained by looking at the source property widgets that have at least > >one dac as a source. > > > >The following command will display source property controls that have > >at least one dac as a possible source. > > > > $ mixerctl -v | grep _source=.*dac > > > >The above command produces the following output on a machine with a > >Sigmatel codec. Output on other machines, even other machine with the > >same codec, likely varies. > > > > outputs.hp_source=dac-0:1 [ dac-0:1 dac-2:3 ] > > outputs.mic_source=dac-0:1 [ dac-0:1 dac-2:3 ] > > outputs.line-in_source=dac-2:3 [ dac-2:3 ] > > outputs.spkr_source=dac-0:1 [ dac-0:1 ] > > outputs.SPDIF_source=dig-dac-0:1 [ dig-dac-0:1 adc-0:1 adc-2:3 adc-4:5 ] > > > >As explained in the manual, the channels that the dacs will convert > >are encoded in the dac names. dac-0:1 converts channels 0 and 1, also > >known as the first stereo pair. In the above output, the hp, mic and > >spkr widgets all have dac-0:1 as their source, and so will receive > >both channels of stereo playback. The line-in widget is configured > >to receive audio from dac-2:3. The line-in widget will therefore > >receive the third and fourth channels, and will not receive any sound > >unless at least 3 channel data is played. > > > >Note that some jacks can be configured for either input or output. > >A jack that is configured for input will not receive any sound > >from it's source. As explained in the manual, the mixer controls > >with the "dir" property name control the direction of the jacks. > > > >The following command will display the current and possible directions > >for jacks whose direction can be changed. > > > > $ mixerctl -v | grep '_dir=' > > > >That command produces the following output on the example Sigmatel > >codec. > > > > outputs.hp_dir=output [ none output input input-vr0 input-vr50 input-vr80 > > ] > > outputs.mic_dir=input-vr80 [ none output input input-vr0 input-vr50 > > input-vr80 ] > > outputs.line-in_dir=input [ none output input input-vr0 input-vr50 > > input-vr80 ] > > outputs.spkr_dir=output [ none output input input-vr0 input-vr50 > > input-vr80 ] > > > >In this configuration, only the hp and spkr widgets will receive sound > >from their sources. > > > Thanks, that was very helpful. > > The direction part is clear except for the input-vr0, input-vr50, > input-vr80. > For what reason would I pick each of these? Is this used to reduce > excessively loud inputs?
to be able to use common consumer microphones, you usually need to have it's jack/pin set for 50% or better VRef. line level inputs should use Hi-Z (0% VRef) which is just 'input'. yes, that needs to be explained better in the manual. > What were or weren't the vendor things? in the case of your codec, nothing. others vary. some are for power saving switches and some completely undocumented. > Do I see this correctly: > I could play 6 channels with mplayer. > 0:1 to one output. > 2:3 to another > 4:5 to adc-4:5 to sp/dif and then decode that stream externally. you can't output to an adc. adc is the opposite of dac. > This would then give 5.1 output. > This may seem a little weird to do, but older Sony 5.1 receivers > that are "broken" with easy to fix cold solder joints are only about > $25 to buy. it may be possible to mix analog and digital output with azalia hardware, but it is not possible with the azalia driver. to be able to do that, there would need to be another layer of connections exposed in the mixer. for now it's either all digital or all analog. -- [email protected] SDF Public Access UNIX System - http://sdf.lonestar.org
