 Я надеюсь, что это будет интересно для вас. Так, давайте поговорим о USB. Я вижу какой-то USB-эксперт здесь. Так, эта баса очень старая. Для сейчас она 23 года старая. Я не знаю, если есть кто-то, который 23, или younger. Нет? 23 старые люди здесь. Да, хорошо. Так что, начиная баса очень старая. Сейчас она 28 гигабитов в секунду. И это очень просто. Так что эта баса из-за спецификации. И просто для использования. Просто у вас есть девайс. У вас есть какие-то USB-порты. Вы можете просто плакать. И это работает просто для вас. Так, какая-то история у USB-эксперт. Первый стандарт был USB-1.0. Релизовый 2.0. Релизовый USB-1.0. Релизовый 2.0 после этого. Следующее. У USB-эксперт обычно redefined some set of generic features or generic functions that you can use with USB. One of that is USB audio class 1. It was released two years after that after our first USB release. Next was USB 2.0, a few years after that. And some manufacturers hugged USB audio class 1 to be working with USB 2.0. There is a hug. Sorry. And six years after that, USB audio class 2.0 was released. Then we have USB 3.0. And of course we need to have USB audio class 3. That will incorporate all functions, only functions that are present in USB 3.0. No. We have USB 3.1. And after that we have USB audio class 3. So it was released more than two years ago. Only last year driver came to the Linux kernel. And I don't know if still there is any hardware that you can buy in the market. Yeah. So USB 3.2. I don't know if you will see any new specification, audio specification after that. So what is USB audio class 1? So it's first audio over USB specification that was released a long time ago. It's something like standard golden standard for Chinese manufacturers. Because usually if you buy some cheap $1 or $2 USB audio card, it will be USB audio class 1. It has also MIDI support. So you can connect your keyboard, piano keyboard and play through. And touch support was added in 2.002 here. So important thing, this specification has also basic audio device support, specification support. So manufacturers who create some new hardware can follow this specification and create their USB audio class hardware using this specification. Because there are many possible configurations and setups that can be done. So just simple case of what it was looking at that time. So just some USB form that you can connect through USB to your PC, for example. It has inputs, outputs, it's terminals and some internal functions. Not only switches, but it can be equalization or some audio processing. Next, audio class 2.0. So, as I already told, hardware manufacturers had audio class 1.0 to be able to work at USB 2.0 speeds. And this was mentioned even in this specification. This was wrong. So there are many improvements, many improvements like audio controls, I did more speakers that can be possible close support. At this time, this specification is usually used by some professional audio devices manufacturers. One issue with this specification is incompatible with the audio class 1.0. That's why people who use Windows, I don't think that any of you use Windows. But Windows, there was always issue with driver for USB audio class 2. So I know that recently, maybe two or three years ago, they added this driver by default to Windows, to Microsoft. In Linux, it was available a long time ago. So it's also one of examples of how your function looks, how your class 2 function. Also, we have input terminals, output terminals, some logic units that can work with audio, some mixers processing feature units. It's a simple case. So if you have some professional audio card, it may be much, much more complicated. So what kind of issues we have with USB audio class 1.0 and 2.0 specifications. If you look at such case, these phones, when they have limited power, limited battery. So first of all, power management was not good. It was designed to be working with some PC laptops with big battery. And compatibility between versions. So if you buy new USB audio stick, USB audio class 2, just plug and work with hots that do not support old new version of driver. So now we have USB audio class 3.0. And what we have? First of all, we have USB super speed support. We have basic audio device profile support. It's mandatory now. Manufacturers who create USB audio card must provide one of BADD profiles. We have power domains. So we can control power. We have connectors. So if you plug your, for example, headphones to USB audio card, hosts can now about this. New strings descriptors. It's more interesting for people who develop driver. Support of link power management from USB 3.0. Burst mode that allows us to transfer more data and then sleep for more time. And it is also incompatible with previous specification BADD. But there is some backward compatibility mode. I will talk about it later. Yeah, important feature. So it's already supported in Linux. It is supported to use even before real hardware exists in the market. So yeah, I hope at the time when real hardware will be present in the market, all of you will be able to just buy it, plug it with two Linux hosts and work with it. So let's start from BADD. What is BADD? So USB audio class specification is quite complex. So any manufacturer can design its own device. That means that people who write USB audio driver should also add this support. In the Linux world we have only one driver and it is in Linux kernel. So for the case when manufacturer added some special feature that is not supported by driver and it doesn't work correctly, there is mandatory support of BADD specification. The issue with this specification, it looks like USB organization wanted to widely adopt this specification so even to use it with some microcontrollers, some simple hosts. So these profiles do not have some class-specific descriptors. And that's the issue. Sorry. You have to guess it. So you have to look at some indirect things, like size of endpoint transfer data, number of endpoints. And finally you have to guess what is this. What is this? But this is useful for hosts that do not have big USB stack. There are three topologies, very simple input-output and input-out. So it's like microphone, headphone and headset. One of stereo, only 48 kilohertz, only 1624 bits. Burst mode and power management. Example. So here is some simple example of input-output topology. We have audio in, which is connected to logical USB in. Logical USB out, which is connected to audio out. We can switch or mix in with out. And this is a simple, very simple topology that should be present on any device. And here we see like two, I don't see. So there are two colors, pink and blue, which reflect part of the maze that we will talk about right now. So if we do not use some part of our USB audio headset or headphone, why we should have the circuits powered up. We can just disable them. So, for example, if you have headphones, headset and you listen to some music and you need to have amplifiers for microphones enabled. So you can just disable. So host can control this and this will save some power for you. Here are some examples. So we have one power domain, first, second power domain. And each can be independently switched on and off or put to some intermediate power states. Now let's talk about compatibility with old hosts. So what kind of issue we have here? Some traditional USB device usually consists of one configuration. USB, one device, just usually one configuration. The support should be audio class one. Same as for USB 2. They are not compatible. But with USB 3, things are more complicated. At least you have support to configurations. First configuration is default configurations and it should be USB 1 or USB 2. That means if you connect your device to some old hosts, this configuration will be selected automatically. And it will work using old functions without old fancy features. But it will work just for you. So even with old Linux or Windows hosts, it will work. Next configuration is also mandatory to support these basic audio device profiles. So if you have some new recent host, USB host with Linux, for example, which already supports this, host can be clever enough to select this configuration. It should be clever enough to support this configuration. But this configuration only has limited set of features. So only two channels, one or two channels or 48 killgears. If you want to have full support of all features that we have with USB audio class, you have to select third configuration. And that's also some difficulties for Linux itself. We'll talk about this later. But at least you can buy some new device. At least you can plug it into old host and it will work somehow, but it will work. So current state. So during last year, many features were merged to Linux kernel. So initially, USB audio class 3 support was merged in 4.17. Then basic audio device profiles support were merged. The issue is that basic audio device profiles was, you have to write like full driver and then you need to somehow incorporate or use somehow to detect, what is the device in BADD mode. So that's why BADD profiles were added later. Tenetter insertion. That's also new feature. USB audio class 3 specification. Was added later. Power domains. So it is supported now. USB configuration switching. That's what's also under discussion some time ago. We'll talk about this later. So configuration switching is now present in the recent, very recent kernel. USB audio class 3 gadget driver. That the thing I was discussing with some maintainers or people who works with USB audio gadgets. Sometime ago I did not finish it yet. And class specific strings parsing is not even started. But all what we need to listen some music, to have power management support, automatic configuration switching is already present in Linux kernel. So just some kind of summary, but some benefits that UACC brings for us. So it will work on all hosts. It will not incorporate new feature, but just work. And it has mandatory BADG profile support. And this also means that if you plug your device to PC, it will just work. Power saving improvements. I never seen this in real life yet. But there is some synopsis proof of concepts. So they measured power consumption and pass, your pass from digital output of some SOC, system machine, then you have another amplifier, some switches or so. And they compared it with USB audio class 3 device, with all power management enabled. And they see that it's comparable. So around the same consumption, power consumption. That's also good for us. It's alternative for 3.5 jack support. I know that it's a Hollywood for all people. I also have a phone. It's a Pixel 3, I think, which does not have jack support. I cannot listen to music when I charge my device. At least it's not only can be used with your phones. It can be used also with your laptops or some other hardware. And it's already supported by Linux. So what every gig expects when he buys some phone, what he wants to have. I'd like to have something like this. At least 12 headphone jacks for big party. Unfortunately, what he will have in the near future, and I think what we have right now, that's what I already have in the road jack. Yeah. So we have some time, so let's talk about changes that we have, that we had during the implementation of this drive. First of all, it's a quality of USB.org documentation. USB implementation forum releases their documentation to USB.org website. Unfortunately, they have many mistakes. I collected the list of that mistakes and wrote an email for them. Please fix it or please give me some real information, because there was some part that were missing in this documentation. So I had to guess them also. I found some examples at the end of this documentation and I found some numbers. I was really surprised, because the quality of the documentation was bad and nobody answered to me. So there was one engineer, Pierre Louis Boussard. He is in the Alsai Linux mailing list, so he is active there, and he was a part of that USB.org committee who worked on this documentation and he shared some previous, part of previous version analysis of this specification. So I was able to pick up all magic numbers from that place. But unfortunately, we still don't have some official release of that. Next issue. How to write a driver for non-existent hardware? Yeah, so that's a really issue. There is one possible case. Use QMU emulation QMU. And there is a dummy RCD kernel module that is something like virtual host and gadget. And you can write some host and gadget drivers so you can emulate your hardware. Unfortunately, it does not support ESO packets, so ESO USB packets. So unfortunately, I was not able to test real audio at the time, but this works, and it speeds up really implementation of new hardware. So, first of all, I just wrote an emulated version of some USB device, USB audio card, and then wrote driver. What the issue here? If I have a bug on one side, I must probably bug on another side. Another approach. Yeah. And another approach. Another approach. Use BigleBone Black. Who knows what is this? BigleBone Black. Wow, that's cool. So, for the rest of people, it's some small board that has USB that can be used as gadget so we can create some USB device inside. I did it next way. So, on PC I implemented UAC3 driver. For BigleBone Black I implemented UAC3 gadget driver. I posted first version of this gadget driver to mailing list. Unfortunately, I did not finish working it still. So, I plug it also some audio card and use it as a loop tool, which just loads audio from one card to another card. And it worked for me. So, if anyone wants to try, you can pick up my old patch UAC3 for gadget, apply it to your BigleBone kernel and just run it. And another challenge. So, since nobody worked with this, nobody wants to know enough reviews. So, the patch was really big. I spent a lot of time writing it and I spent, I think, more time reviewing it by myself. And when I sent it to community, I didn't get any feedback first time. So, nobody works with this hardware, nobody wants to look at this specification. Fortunately, this engineer Pierre Labossard, he did some initial review of my driver. Most of the comments were not relevant. Yeah. It might be that your publication now becomes the standard implementation that everybody will be based on. Yeah. So, fortunately, there was some engineer who worked on some unreleased hardware, who picked up my patch and also started using them. And at the time, he, I hope, did some initial review and testing on some unreleased hardware. Another thing is BDD specification. How to guess descriptors, first and second, how to pass them to ASA subsystem. So, that guy, who worked on unreleased hardware, he created next approach. So, you guess what descriptors are and you just generate them on the fly. Full set of USB descriptors, you emulate full USB audio card. Yeah. Unfortunately, it was big, covered only few profiles. Then another implementation came out. So, just simple implementation and you just check if this is BDD profile, then you know that's one or two channel. So, just simple checking. So, this was much simpler and it was accepted in mainline. And it covered all profiles with the last number of codes. And switching between specifications, between configurations. So, we have three configurations, at least two or three configurations now. How to switch between them? Who should do it? Initially, I did it manually, just using ccFS, write long echo command. I didn't think about that at the time. I wanted community to think about that. I was thinking about something like USB mode switch tool, but maybe it's audio switch tool. Fortunately, some guy just came with approach of switching it in kernel and it was accepted by Greg and fixed again recently. So, that's all from my side. Any questions? I think I wanted to do this from the beginning. So, we've got three configurations. Have you tested this USB gadget? I expect that you implemented the USB function. So, you need to create a gadget. So, you need three different USB functions, right? No, I need three different USB configurations. Yeah, but then you link the same function to three different configurations and create three different behaviors, three different sets of descriptors. Yeah, that's the issue. With USB audio class one or two we don't have this issue, because we use first configuration. And this is my headache with USB audio class three, because I will need to generate many of descriptors that we usually do as static variables, static structures. I had to generate them on the fly. Yeah, and that's the issue with this gadget driver. So, that's why it is not published. Final Russian is not published yet. I'm a little bit lazy. You know, I'm kind of thinking about registering three different USB functions from a single file just, you know, writing dog that this one is desired for the first configuration, this one is desired for the second one, etc. and up to user to decide whether he wants to use it or not. So, it's simply fine. I want to say that there is another issue, actually, a little bit different issue with that. Each USB function creates its own audio card. So, now we have in the system, when you plug and serve this audio gadget to kernel, you will have three audio cards. And that's another issue, how to deal with that. See, audio card is different, set up different functions, different things supported. That's the real issue, I think. I mean, it's the same issue, like the guys had when they, for now it's not possible to implement the equivalent of GATR, because in GATR you have the single Ethernet interface, which was shared between two functions. And then, when we switch to ConfigFS, we cannot create a full equivalent of that, because when we add two functions, we've got two separate network interfaces. So, at that time, there was a discussion that maybe we should somehow rework the gadget framework to allow for matching between resources provided by functions that use these resources to allow that kind of sharing. So, maybe it's a good opportunity to come back to that discussion. Yeah, okay. I wanted, first, to post my patch and then start this discussion, because the real issue is just that it should be audio interfaces. Yeah. Somebody from that side. Yeah. Just to be clear, you don't have to be a USB 3.0 device not to implement the UAC. Yeah. Yeah. So, I can take my old implementation of a sound card and just add the two configurations and that should be fine. Yeah. It's a good one. No, it's a USB audio class 3 interprets features from USB 3.0 specification. But it is not required. It will work even as backward compatible in all the versions of USB. So, I think we run out of time. Yeah. Thank you.