[alsa-devel] HP-path handling on VIA codecs

Wed Jul 13 02:56:20 CEST 2011

2011/7/11 Takashi Iwai <tiwai at suse.de>:
> At Sun, 10 Jul 2011 16:55:45 +0200,
> alex dot baldacchino dot alsasub at gmail dot com wrote:
>>
>>[...]
>>
>> Personally, if I'm not misunderstanding it, I'd vote for C. I had
>> tried something similar for old implementation, and can tell it worked
>> and was easy enough to implement, AFAICT (I can resend the code if
>> found of any interest, since it seems to me my first mail about it
>> went lost, at least that's not in this mailing list archives, though
>> that's based on the old code, and could be useful only to exchange
>> ideas).
>
> A patch will be always useful, even for the older code.
>

Since early May I've been using the same snapshot from tarballs, until
switching to the reworked implementation. However, by the time I've
made several tries and there's more stuff there than loopback
switching. Part of that staff is either useless (such as a few calls
to printk() I used to clear out a few doubts, some of which I had left
behind) or mistaken/unneeded (such as validating the result of
snd_ctl_get_ioffidx() in via_mux_enum_{get,put}), or in a too early
stage/untested (for instance, I was trying to replace 'hard-coded' and
(partly) duplicated switch statements in is_aa_path_mute() and
mute_aa_path() with calls to a function, to unify and simplify both
functions and make maintenance a bit easier, specially if adding a new
codec, but found those switches were different, and wasn't sure
whether they should have been identical - as I thought and still think
- or if there were really some codecs providing infos on actual state
but unable to set the mute bit, and vice-versa, then the
implementation changed radically, thus I gave up with that - and
anyway I wasn't able to test it properly since I have no smart51
control). In general, most of that code is meaningless, because
superseded by actual code, even when it was (seemingly) working (for
instance, I was trying to make part of hp handling more uniform by
creating the same input mux for all codecs, adding a field named
'hp_redirected_mode_index' to struct via_spec and computing its value
basing on a simple assumption: main control 'Independent HP' was
attached either to hp jack nid (for older codecs) or to an audio
selector(for newer ones); in the former case, hp jack is connected to
hp dac and to aa mixer, in turn connected to front dac, in the latter
the audio selector is connected to front and hp dac directly, thus I
was using a function, called by via_hp_build, to scan connection lists
in search of front dac, up to one level in depth, starting at the
control nid - such would have been easier to implement by setting the
right index in each patch_vtxxx() but I didn't find alsa-info.sh data
for all VIA codecs - this way, via_hp_put had just to choose between
independent and redirected index (beside the rest of its
implementation) for all codecs and create_hp_imux() was usable for
VT1702 as well as all other codecs).

Actually, I'm basing my (kind of reference) patch on code resulting
after commit ad2409413d09fca763be1ac5161f2a9d82367903, which seems to
be the last version before major changes in parsing and still close to
the implementation I was basing on, so I think I can use it both to
produce a more readable patch (to show my implementation of loopback
switching in this form) and to take apart the other stuff (part of
which I can send as a separate patch).

Anyway, my implementation of loopback mode switching was aimed to
those newer codecs using an intermediate mixer to connect to both
aa-mixer and to dacs (via an audio selector).

> Regarding ML archive: are you subscribed to ML?  alsa-devel ML is
> basically only for subscribers, and posts from non-subscribers are
> postponed, manually approved.  Sometimes the approval work delayed and
> the posts are canceled.
>
> But, currently alsa-devel ML seems stopped by some reason, so it's
> anyway useless :)
>

Yes, I've created this mail account for subscribing to alsa-devel ML,
after failing to send a mail as non-subscriber from a different
account (and provider).

>>[...]
>> My reason to test such a solution was some noise I constantly got (and
>> still get with newer code, but for Independent HP in latest version)
>> from my headset microphone to each such line out (front and hp), but I
>> can think, for instance, of someone wishing to listen to something
>> while recording something else from line-in and not aiming to mix both
>> sounds in output.
>
> Yes, I think there are both type of users, too.
>

And a 'loopback mode' for playback would be consistent with capture
options allowing to record from 'stereo mixer' or not.

>
>> [...]
>
> Indeed how to name the control element in such a case is a difficult
> problem.  Since the role of the mixer element changes depending on the
> mode, it can't be simply named.  The current naming with "PCM" is
> actually confusing.
>
> Once when we implement the loopback mode-switch, I'd name it like
> "Loopback PCM" or such, to make clear that it belongs only to a
> loopback path.
>

Understood. Perhaps I don't remember well and the old (stand alone)
PCM Volume, in old implementation, just influenced front/aa mixer
gains. And, perhaps, the names of inputs' switch and volume controls
attached to aa mixer could be misleading for someone, since they only
affect this mixer connections and not input lines themselves, while an
average user could think those controls can set values also for
recording from each single input and not only for stereo mixer (in
fact, each of those switches could be used as a 'tricky' mean to
change loopback mode for each single connection to aa mixer while
preserving the possibility to record from a single input line, but
such would compromise/limit the full effectiveness of stereo mixer
capturing).

Attaching a tarball with two diff files. File 'patch_via.aamode.diff'
contains only my attempt to implement a mode switch for aa path (two
input muxs for front and hp, working independently), but for some
lines shared with the other patch and for a few fields in struct
via_spec, and is based on commit
ad2409413d09fca763be1ac5161f2a9d82367903. File 'patch_via.other.diff'
contains other stuff, with some pieces of code that were suggested
and/or inspired by Raymond Yau (like testing effectiveness of nid 0x0b
as hp dac), and is based on aforementioned commit with
patch_via.aamode.diff applied to it.

>
>
> thanks,
>
> Takashi
>

Thanks,

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patches_for_old_impl.tar.gz
Type: application/x-gzip
Size: 8938 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20110713/080b0e8a/attachment.gz 