AudioInputUSB : muting does not work (Win 10)

Frank B

Senior Member
AudioInputUSB : On my system, muting does not work (volume slider works).

2021-06-22 10_58_22-Window.png

Teensy 4
 
Last edited:
Good find! I verified on a Teensy 4.0 as well and indeed mute is not working [the slider volume does].
On a Teensy 3.2, mute does work [as well as the slider volume].
Used this code to verify on both T4.0 and T3.2:
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

AudioInputUSB            usb1;
AudioOutputI2S           i2s1;
AudioConnection          patchCord1(usb1, 0, i2s1, 0);
AudioConnection          patchCord2(usb1, 1, i2s1, 1);
AudioControlSGTL5000     sgtl5000_1;

void setup() {
  Serial.begin(9600);
  AudioMemory(12);
  sgtl5000_1.enable();
  sgtl5000_1.volume(0.6);
}

void loop() {
  // read the PC's volume setting
  float vol = usb1.volume();
  Serial.println(vol);
  delay(100);
}

May dive into this issue coming weekend...my brains are needed for other things now.

Gruesse,
Paul
 
modified usb_audio.cpp:
Code:
int usb_audio_set_feature(void *stp, uint8_t *buf) 
{
    struct setup_struct setup = *((struct setup_struct *)stp);

    Serial.println(setup.bCS);
    Serial.println(setup.bRequest);

    if (setup.bmRequestType==0x21) { // should check bRequest, bChannel and UnitID
            if (setup.bCS==0x01) { // mute
                if (setup.bRequest==0x01) { // SET_CUR
                    AudioInputUSB::features.mute = buf[0]; // 1=mute,0=unmute
                    AudioInputUSB::features.change = 1;
                    return 1;
                }
            }
....
Interestingly, the code above prints nothing on mute /unmute, so I think it might be a problem with the descriptor.

Yes, doing other things now, too. Will be interesting what you find.

Frank
 
Descriptor:
Code:
[B]
        -------- Audio Control Feature Unit Descriptor --------
bLength                  : 0x0A (10 bytes)
bDescriptorType          : 0x24 (Audio Interface Descriptor)
bDescriptorSubtype       : 0x06 (Feature Unit)
bUnitID                  : 0x31 (49)
bSourceID                : 0x03 (3)
bControlSize             : 0x01 (1 byte per control)
bmaControls[0]           : 0x01
 D0: Mute                : 1
 D1: Volume              : 0
 D2: Bass                : 0
 D3: Mid                 : 0
 D4: Treble              : 0
 D5: Graphic Equalizer   : 0
 D6: Automatic Gain      : 0
 D7: Delay               : 0
bmaControls[1]           : 0x02
 D0: Mute                : 0
 D1: Volume              : 1
 D2: Bass                : 0
 D3: Mid                 : 0
 D4: Treble              : 0
 D5: Graphic Equalizer   : 0
 D6: Automatic Gain      : 0
 D7: Delay               : 0
bmaControls[2]           : 0x02
 D0: Mute                : 0
 D1: Volume              : 1
 D2: Bass                : 0
 D3: Mid                 : 0
 D4: Treble              : 0
 D5: Graphic Equalizer   : 0
 D6: Automatic Gain      : 0
 D7: Delay               : 0
iFeature                 : 0x00 (No String Descriptor)
Data (HexDump)           : 0A 24 06 31 03 01 01 02 02 00                     .$.1......
[/B]
 
Couldn't resist and was already comparing C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\usb_audio.cpp and C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_audio.cpp.
Identical with respect to "int usb_audio_get_feature(void *stp, uint8_t *data, uint32_t *datalen)".
And indeed both Audio Control Feature Unit Descriptors are the same for T4.0 and T3.2.

To be continued...
Paul
 
? What do you mean?
2014, there was no Teensy 4

Usually I test my PRs before committing them.. so yes it works for me.

In the repo you've put the PR in, there are no fewer than 61 open Pull Requests, the oldest going back as far as 2014. Quite a few are yours, as it happens. So I'm just curious as to whether putting in a PR actually results in the fix ending up as part of the codebase.

Hmmm ... that's interesting ... as I've been writing the open PR count has gone down to 58 ... maybe someone is watching!

Obviously some PRs will be stale by now (I hope so), or rejected. Not yours, I imagine, I'm sure you test your code properly, as you say!

Cheers

Jonathan
 
LOL, yes, indeed I closed now some of my older still open pullrequests. I do that from time to time, when there is no repsonse from anyone.
Yes, I test all of them - at least I try it. Sometimes, despite of that, i add new bugs.. but not in this case :)

Have you counted the merged PRs since 2014? I'd do that.

Yes, not all PRs make sense. Some fix problems that are no real problems and are not needed. Some others are just not useful.
Others are indeed useful.
Some guys put hours of work to create a PR. I can understand that it is not nice to get any reaction.
This situation was the same *before* corona, too.

Just live with it :)
If there is a needed PR or urgend BugFix you can be pretty sure that it gets merged.
 
Last edited:
Sure, I did see there were many more closed than still open, though I didn't look to see how many were merged and how many just dried up and blew away...

Know what you mean about putting bugs in when doing a fix, been there many times :D

At the end of the day I guess it's just that Paul has limited bandwidth, and clearly a lot on his plate right now with chip shortages & Covid.
 
Back
Top