All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Mack <daniel@zonque.org>
To: Tobias Hoffmann <smilingthax@googlemail.com>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, robin@gareus.org,
	clemens@ladisch.de,
	David Henningsson <david.henningsson@canonical.com>
Subject: Re: [WIP PATCH] Scarlett mixer interface for 6i6, 18i6, 18i8 and 18i20.
Date: Thu, 09 Oct 2014 10:31:15 +0200	[thread overview]
Message-ID: <543647D3.9070004@zonque.org> (raw)
In-Reply-To: <5435BF95.2040909@googlemail.com>

Hi Tobias,

On 10/09/2014 12:49 AM, Tobias Hoffmann wrote:
> And some more comments from me:
> 
> On 08/10/14 21:04, Daniel Mack wrote:
>> +
>> +/* #define WITH_METER */
>> +/* #define WITH_LOGSCALEMETER */
>> These should either be converted to module parameters, or removed
>> alltogether. Why are they configurable, anyway?
> 
> As I've said in my earlier mail, code is current not working: Metering 
> should be removed from this patch (or rewritten to use hwdep-API).
> 
>>> +#define LEVEL_BIAS 128  /* some gui mixers can't handle negative ctl values (alsamixergui, qasmixer, ...) */
>>> +
>>> +#ifndef LEVEL_BIAS
>>> +	#define LEVEL_BIAS 0
>>> +#endif
>> Same here.
> As LEVEL_BIAS = 0 definitely causes problems with some mixer GUIs, the 
> #ifndef ... #endif should be removed completely.

Alright. David, will you be working on new version of the patch?

>>> +#if 0 /* rg debug XXX */
>>> +	snd_printk(KERN_ERR "req ctl value: req = %#x, rtype = %#x, wValue = %#x, wIndex = %#x, size = %d\n",
>>> +		   bRequest, (USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN), wValue, idx, size);
>>> +#endif
>> That can be moved to snd_printdd()
> 
> These are left overs from Robins code, even I didn't need them. It's 
> probably safe to just remove all the
>    #if 0 /* rg debug XXX */  ... #endif
> from the patch.

Sure it's safe, as dead code doesn't do anything :) The question is
whether the line produces any useful information for people having
trouble with their device. If so, we can just convert it to snd_printdd().

>>> +static int scarlett_ctl_save_put(struct snd_kcontrol *kctl, struct snd_ctl_elem_value *ucontrol)
>>> +{
>>> +	struct scarlett_mixer_elem_info *elem = kctl->private_data;
>>> +	int err;
>>> +
>>> +	if (ucontrol->value.enumerated.item[0]>  0) {
>>> +		char buf[1] = { 0xa5 };
>>> +
>>> +		err = set_ctl_urb2(elem->mixer->chip, UAC2_CS_MEM, 0x005a, 0x3c, buf, 1);
>>> +		if (err<  0)
>>> +			return err;
>>> +
>>> +		snd_printk(KERN_INFO "Scarlett: Saved settings to hardware.\n");

Btw - this should become a debug print as well.

>>> +	}
>>> +
>>> +	return 0; /* (?) */
>> What's the confusion here? :)
> 
	> The "Save to HW" enum uses a special kcontrol .get/.put combo:
> .get always returns 0, and .put issues a special command to the hardware.
> 
> I not 100% sure what the "best" return value of the .put function would 
> be in that case.
> AFAIUI, .put functions have to return whether the value has changed... 
> and here:
>   - something happend (supporting return 1;)
>   - but .get still returns 0 (supporting return 0;)

Ah, I see. Yes, I'd consider that a misuse of the ALSA control API, as
you're not dealing with an actual control here. I think that should
become a hwdep interface then.

> But I found this...:
>> +static struct snd_kcontrol_new usb_scarlett_ctl_save = {
>> +	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
>> +	.name = "",
>> +	.info = scarlett_ctl_enum_info,
>> +	.get =  scarlett_ctl_save_get,
>> +	.get =  scarlett_ctl_save_put,
>> +};
> 
> BUG! .get is set twice instead of .get and .put...

Right, so the code in .put was never actually used, right? Did the
compiler not warn about that?

> Testing is definitely needed for that change.
> 
>>> +/*  untested...  */
>>> +static const struct scarlett_device_info s6i6_info = {
>> Would be nice to get some testers here.
> 
> I did heard of one person who used it (successfully) on s6i6.
> That's not to say that we should not test the "final" patch on each device.

Yes, that would be good.

>> Here, and in some other occasions, ARRAY_SIZE() should be used.
>>
>>> +	.opt_matrix = {
>>> +		.start = -1,
>>> +		.len = 27,
>>> +		.texts = s18i8_texts
>>> +	},
>> Same here.
> 
> ARRAY_SIZE(s18i8_text) == 35, so  .len = (ARRAY_SIZE()-8) ?
> I not sure that's helpful...
> The better way to think about it is:
>    .opt_matrix.len = .mix_start + 1,
>    .opt_master.len = .opt_matrix.len + .matrix_out    // == ARRAY_SIZE()

Hmm, yes. I was just thinking about something that makes the values look
a bit less magical.


Daniel

  reply	other threads:[~2014-10-09  8:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07 15:16 [WIP PATCH] Scarlett mixer interface for 6i6, 18i6, 18i8 and 18i20 David Henningsson
2014-10-07 15:24 ` Tobias Hoffmann
2014-10-08 19:04 ` Daniel Mack
2014-10-08 21:21   ` Robin Gareus
2014-10-08 22:06     ` Tobias Hoffmann
2014-10-09  8:39     ` Takashi Iwai
2014-10-08 22:49   ` Tobias Hoffmann
2014-10-09  8:31     ` Daniel Mack [this message]
2014-10-09 10:13       ` Tobias Hoffmann
2014-10-13 13:30       ` David Henningsson
2014-10-09  8:35   ` Takashi Iwai
2014-10-13 10:58 ` Tobias Hoffmann
2014-10-13 11:38   ` Clemens Ladisch
2014-10-13 12:02     ` Tobias Hoffmann
2014-10-13 12:09       ` Clemens Ladisch
2014-10-13 12:21         ` Tobias Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=543647D3.9070004@zonque.org \
    --to=daniel@zonque.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=david.henningsson@canonical.com \
    --cc=robin@gareus.org \
    --cc=smilingthax@googlemail.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.