| Message ID | 20230523075358.9672-1-tiwai@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | ALSA: Add MIDI 2.0 support | expand |
Hello I have a few questions:
1. As default, USB-audio driver will take the alternate setting for MIDI 2.0 interface: Does this mean that the ALSA driver will default to Alt Function 1 if it exists ?
2. What happens when using a kernel that does not support Alt Function 1 (MIDI 2.0) and device with a (much longer) MIDI 2.0 descriptor is attached ?
3. " However, user may let the driver falling back to the old MIDI 1.0 interface by a module option, too."
Can or how it this done via the ALSA API ? If the switch is made, does an ALSA client require to re-enumerate all the ports ?
4. Is there a way to force a specific device (port) to Legacy MIDI 1.0 ?
5. Is there a way , via ALSA, to select UMP MIDI 1.0 protocol instead of MIDI 2.0 UMP protocol.
6. To which protocol does the driver default ? UMP MIDI 1.0 or UMP MIDI 2.0 ?
7. Does the driver do anything related to Jitter Reduction ? How/is this supported via the ALSA API ?a
8. Does the driver do anything related to Bandwidth restriction ? How/is this supported via the ALSA API ?
9. Are/will UMP streaming messages be supported ? (new feature in MIDI 2.0 specification), if yes, how ?
10. Is function block information supported via ALSA, i.e added in the ALSA Port information ?
On Tue, 13 Jun 2023 14:41:07 +0200, happy.debugging@gmail.com wrote: > > Hello I have a few questions: > > 1. As default, USB-audio driver will take the alternate setting for MIDI 2.0 interface: Does this mean that the ALSA driver will default to Alt Function 1 if it exists ? Yes. > 2. What happens when using a kernel that does not support Alt Function 1 (MIDI 2.0) and device with a (much longer) MIDI 2.0 descriptor is attached ? It falls back to MIDI 1.0 interface. > 3. " However, user may let the driver falling back to the old MIDI 1.0 interface by a module option, too." > Can or how it this done via the ALSA API ? You can't. Only via a module option or kconfig. > If the switch is made, does an ALSA client require to re-enumerate all the ports ? > 4. Is there a way to force a specific device (port) to Legacy MIDI 1.0 ? If demanded, we can implement a device-specific quirk for that. > 5. Is there a way , via ALSA, to select UMP MIDI 1.0 protocol instead of MIDI 2.0 UMP protocol. Use the UMP 1.1 Streaming command to switch the protocol. > 6. To which protocol does the driver default ? UMP MIDI 1.0 or UMP MIDI 2.0 ? Whatever the device sets as default. > 7. Does the driver do anything related to Jitter Reduction ? How/is this supported via the ALSA API ?a JRTS is sent as normal UMP packet (also as sequencer events). No particular API is provided for JRTS, so far. > 8. Does the driver do anything related to Bandwidth restriction ? How/is this supported via the ALSA API ? Currently no restriction is. The bandwidth is provided via the API, but it's only for information. > 9. Are/will UMP streaming messages be supported ? (new feature in MIDI 2.0 specification), if yes, how ? It was already implemented in kernel UMP core. See the recent posts. > 10. Is function block information supported via ALSA, i.e added in the ALSA Port information ? Ditto. Takashi
Many thanks, it seems that you already receive the new specs :-) BTW I just joined this list, any my email address is shown in posts instead of the username as for other member is there a contact for this list (webmaster) to discuss this ? I could not find any contact for the admin. Item 5. assume this is 7.1.6.2 Stream Configuration Request / 7.1.6.4 Stream Configuration Notification. Can it be done via the ALSA API ?
On Tue, 13 Jun 2023 15:24:11 +0200, Happy Debugging wrote: > > Many thanks, it seems that you already receive the new specs :-) Yes, I was involved with the spec definition, too. And, Linux/ALSA patches have been internally reviewed and discussed with MAA MIDI 2.0 WG for months before publishing. > BTW I just joined this list, any my email address is shown in posts instead of the username as for other member > is there a contact for this list (webmaster) to discuss this ? I could not find any contact for the admin. I guess it's rather your mailer setup? > Item 5. assume this is 7.1.6.2 Stream Configuration Request / 7.1.6.4 Stream Configuration Notification. > Can it be done via the ALSA API ? You can send a UMP packet. Takashi
So great that the Linux community got involved early. :-) Mailer issue resolved, It seems it needs some time to take effect. "You can send an UMP packet" => it means to the raw midi device /dev/snd/umpC*D* ? That is not via an ALSA API call (yet) ?
I could not find the changes and UMP source files on https://github.com/torvalds/linux/tree/master/sound, is that correct ? I am trying to build a kernel with UMP support for testing UMP on a custom made development board.
On Wed, 14 Jun 2023 08:01:39 +0200, Symbolic Debugger wrote: > > I could not find the changes and UMP source files on https://github.com/torvalds/linux/tree/master/sound, is that correct ? > I am trying to build a kernel with UMP support for testing UMP on a custom made development board. All MIDI 2.0 stuff will be merged to 6.5 kernel. Currently it's found in linux-next or sound.git subsystem tree. In sound.git tree, you can find some branches for the use on older kernels, too (topic/midi20, topic/midi20-6.1.y, topic/midi20-5.15.y, topic/midi20-5.10.y, topic/midi20-5.4.y). Takashi
On Wed, 14 Jun 2023 08:09:37 +0200, Takashi Iwai wrote: > > On Wed, 14 Jun 2023 08:01:39 +0200, > Symbolic Debugger wrote: > > > > I could not find the changes and UMP source files on https://github.com/torvalds/linux/tree/master/sound, is that correct ? > > I am trying to build a kernel with UMP support for testing UMP on a custom made development board. > > All MIDI 2.0 stuff will be merged to 6.5 kernel. > Currently it's found in linux-next or sound.git subsystem tree. > > In sound.git tree, you can find some branches for the use on older > kernels, too (topic/midi20, topic/midi20-6.1.y, topic/midi20-5.15.y, > topic/midi20-5.10.y, topic/midi20-5.4.y). FWIW, sound.git tree is found at: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/ Takashi
That was indeed worth a lot. Built this sound.git on two machines: make menuconfig enabled: * MIDI 2.0 Support by USB audio driver * Support for UMP Events Save to .config make Found to .ko files in usb folder: snd-usb-audio.ko sndmidi-lib.ko Ubuntu 22.04 LTS (Linux H3 5.19.0-43-generic #44~22.04.1-Ubuntu) with 5.19 HWE Stack Option sudo insmod snd-usb-audio.ko insmod: ERROR: could not insert module snd-usb-audio.ko: Invalid module format Ubuntu 23.04 (runs in KVM) (Linux Ubuntu 6.2.0-20-generic) sudo insmod snd-usb-audio.ko insmod: ERROR: could not insert module snd-usb-audio.ko: Unknown symbol in module [37207.309239] snd_usb_audio: Unknown symbol snd_ump_receive (err -2) [37207.309275] snd_usb_audio: Unknown symbol media_entity_pads_init (err -2) [37207.309289] snd_usb_audio: Unknown symbol media_remove_intf_link (err -2) [37207.309311] snd_usb_audio: Unknown symbol snd_usbmidi_resume (err -2) [37207.309420] snd_usb_audio: Unknown symbol media_device_delete (err -2) [37207.309434] snd_usb_audio: Unknown symbol snd_ump_endpoint_new (err -2) [37207.309440] snd_usb_audio: Unknown symbol media_devnode_create (err -2) [37207.309449] snd_usb_audio: Unknown symbol media_device_unregister_entity (err -2) [37207.309460] snd_usb_audio: Unknown symbol snd_usbmidi_disconnect (err -2) [37207.309468] snd_usb_audio: Unknown symbol media_device_usb_allocate (err -2) Can it be done on 6.2 or 5.15 ? How to insert the new module or build it so it can be used with a current kernel ? How to proceed in case the existing module is use (rmmod) ? Canoncial does not provide kernel sources for newer kernels than 6.2 , like 6.4.0.rc2 of this sound.git, at least could not find them, but I did successfully built the 6.2 and 5.15 Ubuntu distro kernels already from their respective sources. Just copy the sound/usb and sound/core files over the current kernel sources, recompile it (of-course with and updated version number).
Well never mind... Finally ! uname -a Linux Ubuntu 6.4.0-rc6-next-20230615 #3 SMP PREEMPT_DYNAMIC Fri Jun 16 17:48:44 CST 2023 x86_64 x86_64 x86_64 GNU/Linux
On Fri, 16 Jun 2023 14:23:02 +0200, Symbolic Debugger wrote: > > Well never mind... Finally ! > > uname -a > Linux Ubuntu 6.4.0-rc6-next-20230615 #3 SMP PREEMPT_DYNAMIC Fri Jun 16 17:48:44 CST 2023 x86_64 x86_64 x86_64 GNU/Linux Good to hear that you made it :) Actually, backporting the patches to 6.2 should be trivial, too. You can simply rebase the commits between v6.4-rc2..topic/midi20 onto 6.2 or 6.3 base. As mentioned, the backports for other LTS branches are found on sound.git tree, which required a few more pieces and some corrections. Takashi
Thanks a lot for the reply. I could try to re-base/backport the change onto the 6.2 kernel, but I am not very versed in git.. If there is a pointer to where how to do this backport, would be great. Now that I am on 6.4, the first step is to let the umpCxDx USB MIDI 2.0 device show up and then enumerate the ALSA ports (RAW or Sequencer) [ just C code] to find it there as well. P.S: I am not sure if this is the right place for the long conversation and support on this. I could create a server/channel on Discord.
An Attempt to replay the changes to 6.2 : starting with linux-next (On branch next-20230614) as master According to tag 6.4-rc2 the commit for it is f81fe2a4874338a1bfc599cae903a6101217b0a5 # reset the master to 6.4-rc2: $git reset --hard 581fe2a4874338a1bfc599cae903a6101217b0a5 $git checkout v6.2 Previous HEAD position was f1fcbaa18b28 Linux 6.4-rc2 HEAD is now at c9c3395d5e3d Linux 6.2 $git rebase master Successfully rebased and updated detached HEAD. $git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'. $git merge master Already up to date. Running menuconfig, there are no option for MIDI 2.0 / UMP, though the Makefile shows 6.4-rc6 and the ump files are in the source tree.
On Sat, 17 Jun 2023 17:07:56 +0200, Symbolic Debugger wrote: > > An Attempt to replay the changes to 6.2 : > starting with linux-next (On branch next-20230614) as master > According to tag 6.4-rc2 the commit for it is f81fe2a4874338a1bfc599cae903a6101217b0a5 > # reset the master to 6.4-rc2: > $git reset --hard 581fe2a4874338a1bfc599cae903a6101217b0a5 > $git checkout v6.2 > Previous HEAD position was f1fcbaa18b28 Linux 6.4-rc2 > HEAD is now at c9c3395d5e3d Linux 6.2 > $git rebase master > Successfully rebased and updated detached HEAD. > $git checkout master > Switched to branch 'master' > Your branch is up to date with 'origin/master'. > $git merge master > Already up to date. > Running menuconfig, there are no option for MIDI 2.0 / UMP, though the Makefile shows 6.4-rc6 and the ump files are in the source tree. Try the following: % cd /somewhere/linux-next % git reset --hard febdfa0e9c8a5d3a3d895245d1c294c26787daef % git rebase --onto v6.2 v6.4-rc2 The commit febdfa is the topmost commit of MIDI 2.0 stuff. This will plant the MIDI 2.0 stuff onto 6.2. Alternatively: % cd /somewhere/linux-stable % git fetch /somewhere/linux-next febdfa0e9c8a5d3a3d895245d1c294c26787daef % git reset --hard FETCH_HEAD % git rebase --onto origin/linux-6.2.y v6.4-rc2 This will be onto the latest 6.2.y stable, instead. If v6.4-rc2 tag isn't found, replace it with f1fcbaa18b28. Takashi
All kernel 6.2 files build successfully ! P.S. I saw a reference to you on the NAMM booth. :-) Thank you so much !
I have a few question on the implementation 1. As stated above: So the driver may support multiple UMP Endpoints in theory, although most devices are supposed to have a single UMP EP that can contain up to 16 groups -- which should be large enough. I read (forgot where) that Windows will only supports 1 endpoint) . This would results in maximum 16 I/O ports when using one group terminal block per endpoint. Correct ? In that case manufacturers may not create devices with multiple endpoints ... :-) ? Per USB spec, One endpoint can support maximum 16 terminal blocks with each 16 groups so one endpoint in theory could support 256 (bi directional) groups and thus 512 ports (256 in/ 256 out) 2. If there is one in and and out terminal in an endpoint, then this will be presented as one in and one output port (in ALSA) ? Correct ? 3. bGrpTrmBlkType: are 0x00, 0x01 and 0x02 all supported ? 4. At the MIDI device, should OUT endpoints be BULK, and IN endpoints be INTERRUPT or BOTH BULK ? Page 21 of MIDI spec shows BULK for in and out but the descriptor example shows interrupt for IN. Page 19 states: MIDI Streaming Data Endpoints use bulk or interrupt transfers to exchange data with the Host 5. Are more than 1 Group Terminal Blocks supported by the driver for one endpoint ? 6. The current driver already uses the Group Terminal Blocks Descriptors Request ?
On Wed, 28 Jun 2023 08:52:25 +0200, Symbolic Debugger wrote: > > I have a few question on the implementation > > 1. As stated above: So the driver may support multiple UMP Endpoints in theory, although most devices are supposed to have a single UMP EP that can contain up > to 16 groups -- which should be large enough. > > I read (forgot where) that Windows will only supports 1 endpoint) . This would results in maximum 16 I/O ports when using one group terminal block per endpoint. Correct ? In that case manufacturers may not create devices with multiple endpoints ... :-) ? Yes, that's my point in the above. It's not much expected that there will be multiple (UMP) Endpoints on a single device. In theory it's still possible, and the Linux driver supports it, but for now, it's supposed to be exceptional. Other OS don't seem supporting multiple EPs, in anyway. > Per USB spec, One endpoint can support maximum 16 terminal blocks with each 16 groups so one endpoint in theory could support 256 (bi directional) groups and thus 512 ports (256 in/ 256 out) One UMP EP can have up to 32 Function Blocks. But the actual limitation is rather the max number of UMP Groups (16) contained in a single EP. > 2. If there is one in and and out terminal in an endpoint, then this will be presented as one in and one output port (in ALSA) ? Correct ? Not really, GTB or FB are merely meta data representing the associations of UMP Groups on a UMP Endpoint. The Groups included in a FB can be even changed dynamically during the runtime, too. The actual input and output entities are UMP Groups, which correspond to the former MIDI ports. GTB and FB indicate how those are tied. BTW, a UMP Endpoint represents the bidirectional I/O by itself, so it's a pair of USB Endpoints. > 3. bGrpTrmBlkType: are 0x00, 0x01 and 0x02 all supported ? Yes. > 4. At the MIDI device, should OUT endpoints be BULK, and IN endpoints be INTERRUPT or BOTH BULK ? Page 21 of MIDI spec shows BULK for in and out but the descriptor example shows interrupt for IN. Page 19 states: MIDI Streaming Data Endpoints use bulk or interrupt transfers to exchange data with the Host AFAIK, in most cases, INT is used for MIDI 2.0 USB Input Endpoint, while BULK is used for USB Output Endpoint. (On USB MIDI 1.0 spec, both are BULK, although there have been a few vendor-specific variants, too). But the driver can work in ether way. It just depends on the USB descriptor. > 5. Are more than 1 Group Terminal Blocks supported by the driver for one endpoint ? Yes, and that's the very key point of MIDI 2.0. > 6. The current driver already uses the Group Terminal Blocks Descriptors Request ? Yes and no. On Linux driver, GTBs are referred at first only to find out a MIDI Endpoint pair. Then, the driver tries to issue the new UMP 1.1 Stream message to obtain the UMP Endpoint and Function Block information. On older devices that don't under those UMP 1.1 messages, the driver falls back and uses GTBs as the primary source for building a topology. Takashi
Thanks for the notes. I read the (USB) spec again page 27/28. (well multiple times) and as I understood 1 endpoint has 1 or more multiple Group Terminal Blocks for which GTB each has 1 to 16 groups (group = in/out or bi = similar to one or two midi cables/ports) per terminal block The spec I have is from May 5th, 2020. i wonder how the driver get the Function Block information function blocks are not mentioned in the USB spec. Is there a a newer USB spec? if yes, it may make no sense to develop a device now if the descriptors and USB functions calls changed. Page 28 still refers to MIDI -CI protocol negotiation which already has been removed. It's a bit confusing. Would have been better to first release the updated USB spec before releasing the updated MIDI specs.
On Wed, 28 Jun 2023 13:32:12 +0200, Symbolic Debugger wrote: > > Thanks for the notes. I read the (USB) spec again page 27/28. (well multiple times) and as I understood 1 endpoint has 1 or more multiple Group Terminal Blocks for which GTB each has 1 to 16 groups (group = in/out or bi = similar to one or two midi cables/ports) per terminal block The spec I have is from May 5th, 2020. i wonder how the driver get the Function Block information function blocks are not mentioned in the USB spec. Is there a a newer USB spec? if yes, it may make no sense to develop a device now if the descriptors and USB functions calls changed. Page 28 still refers to MIDI -CI protocol negotiation which already has been removed. It's a bit confusing. Would have been better to first release the updated USB spec before releasing the updated MIDI specs. Basically a UMP EP can have up to 16 groups, and GTB indicates which groups out of those can be managed together. And for the old USB MIDI 2.0 spec, groups in multiple GTBs have to be unique; i.e. if GTB#1 contains the group#1, the group#1 can't be found in another GTBs. OTOH, the new UMP 1.1 spec allows the shared groups by multiple Function Blocks. For explicitly disallowing this new (rather confusing) behavior, "static block" flag was added in the FB info. When this bit is set, the FB is fixed and doesn't overlap, so that it's more or less compatible with GTB. Note that Function Block is a new thing that was defined in UMP 1.1 spec. Naturally it didn't exist in the old USB MIDI 2.0 spec of year 2020. But, the concept of Function Block (and implementation) is rather about UMP, and it's independent from the transport layer; that is, USB MIDI 2.0 spec still applies as is, and won't be updated soon, AFAIK. It's a matter of the driver which information is used as the primary source: FB or GTB. The device should provide both info, in somehow compatible ways. Takashi
Thanks again for your time to reply . I think my coin has dropped :-) 1 .So basically, we have GTB in the device descriptor and the FB information is an UMP call to the device by the ALSA driver. "The device should provide both info, in somehow compatible ways." . The process would be [a]. driver gets USB device descriptors, [b]. driver issues USB call to retrieve USB GTB descriptors and then [c] driver issues UMP stream call to retrieve the function block information. (if N/A, driver falls back on the GTB information). This information should be consistent with the groups defined in the GTB. 2. When creating the device descriptors and GTB descriptors based on the 2020 USB 2.0 spec, it should work ? Would those port show up in ALSA or can only be access via /dev/umpC*D* 3. w/o duplicates with 2 GTB's and for 32 groups, for example, it would be 1st GTB has group 1~16 and 2nd GTB 17~23 ?. A FB could use the groups from both GTB's for example Group1 and 17. 4. If two functions uses all 16 groups, that would use up all 32 FB's , correct ?
On Thu, 29 Jun 2023 04:03:47 +0200, Symbolic Debugger wrote: > > Thanks again for your time to reply . I think my coin has dropped :-) > > 1 .So basically, we have GTB in the device descriptor and the FB information is an UMP call to the device by the ALSA driver. "The device should provide both info, in somehow compatible ways." . The process would be [a]. driver gets USB device descriptors, [b]. driver issues USB call to retrieve USB GTB descriptors and then [c] driver issues UMP stream call to retrieve the function block information. (if N/A, driver falls back on the GTB information). This information should be consistent with the groups defined in the GTB. Correct. > 2. When creating the device descriptors and GTB descriptors based on the 2020 USB 2.0 spec, it should work ? Would those port show up in ALSA or can only be access via /dev/umpC*D* Yes, there has been no change about the GTB itself; USB MIDI spec is unchanged. The recent MIDI 2.0 spec extended only UMP and MIDI-CI. > 3. w/o duplicates with 2 GTB's and for 32 groups, for example, it would be 1st GTB has group 1~16 and 2nd GTB 17~23 ?. A FB could use the groups from both GTB's for example Group1 and 17. First of all: you can't have more than 16 groups (per direction) on a single EP. It's a hard limitation. So there can be no "Group 17". (A UMP Group can be bidirectional.) Imagine other way round: you have max 16 in and 16 out UMP Groups where each Group has 16 channels, and GTB and FB just define how those Groups are assigned to which actual I/O. Some multiple Groups may belong to the I/O for the same purpose, and in that case, those Groups can be put into a single FB / GTB. > 4. If two functions uses all 16 groups, that would use up all 32 FB's , correct ? If each FB contains one (single direction) Group and you have 16 in and 16 out Groups, then yes, it'll be up to 32 FBs and GTBs, which is the max number defined in the spec. But a FB / GTB can contain multiple Groups for the same purpose, so I guess taking all 32 FBs would be rather a rare case. Takashi
Thanks again. Its getting much clearer now. To summarize: [a] more than 1 Group Terminal Blocks are supported by the driver for one endpoint, but [b] you can't have more than 16 groups (per direction) on a single EP. and [c] if devices (mainly due to Windows) only support 1 EP, that would mean when using two GTB for 16 groups, one device cannot go beyond the 16 group limit. That would mean - in a rare corner case - to design ay a USB UMP (MIDI 1.0) interface that has legacy DIN I/O it can't go beyond 16 in and 16 OUT DIN connectors. Perhaps a logical use for multiple GTB is to use one GTB per function, but on the others hand designers would probably won't take all that hassle if that if they can do with one GTB for all the functions, and mostly devices have two functions, one for voice data an one for firmware updates or other non-voice purposes.
I wish to program (C) against the new ALSA drivers. Understandably the current alsa-lib one is for the current kernel (up to 6.4) but since I have the kernel installed, I don't have the .h and .so files and distro's may include the packages (libasound) even later. Is there a interim library available before the kernel and distro's are updated ?
On Mon, 03 Jul 2023 12:15:59 +0200, Symbolic Debugger wrote: > > I wish to program (C) against the new ALSA drivers. Understandably the current alsa-lib one is for the current kernel (up to 6.4) but since I have the kernel installed, I don't have the .h and .so files and distro's may include the packages (libasound) even later. Is there a interim library available before the kernel and distro's are updated ? The build of alsa-lib doesn't rely on the kernel headers installed on your system, as it has its own copies in the tree. You just need to update alsa-lib from the latest git version. Takashi
That's what I thought and checked, but did not see newfile, but now I do, Perhaps I checked a wrong repo. I pulled the latest repo, compiled (gitcompile) but it did not generate .so but it reports lot of .lo files. I wish not to overwrite the current libasound.so., so should it be : make install with --libdir=<my directory> to generate the .so files ?
On Mon, 03 Jul 2023 13:25:14 +0200, Symbolic Debugger wrote: > > That's what I thought and checked, but did not see newfile, but now I do, Perhaps I checked a wrong repo. I pulled the latest repo, compiled (gitcompile) but it did not generate .so but it reports lot of .lo files. I wish not to overwrite the current libasound.so., so should it be : make install with --libdir=<my directory> to generate the .so files ? You can try to install it to a temporary directory specified via DESTDIR variable as a test. Also, the libasound.so.2.0.0 can be found under src/.libs directory after the build. You can simply copy that, too. But, for general build issues, better to ask your distro. Someone might have already a package built from the git repo, too. Takashi
Great ! Found the files. Thanks so much. BTW found the discrepancy. I downloaded the 1.2.9 alsa-lib (tar) files from the alsa website which did not have ump files as they do in the git 1.2.9 repo. I found this https://packages.ubuntu.com/search?keywords=asound Seems libasound2-dev is based on 1.2.9 but is for the next distro release (23.10) . Strangely, in the file list there are no ump files.
On Mon, 03 Jul 2023 14:54:16 +0200, Symbolic Debugger wrote: > > Great ! Found the files. Thanks so much. BTW found the discrepancy. I downloaded the 1.2.9 alsa-lib (tar) files from the alsa website which did not have ump files as they do in the git 1.2.9 repo. I found this https://packages.ubuntu.com/search?keywords=asound Seems libasound2-dev is based on 1.2.9 but is for the next distro release (23.10) . Strangely, in the file list there are no ump files. 1.2.9 is the already released one. The UMP support *will* be included in 1.2.10, once when released. The git version is a bleeding edge code, that is, would-be-1.2.10. Takashi
Thank you much. I should have everything now to start building.
A question about the implementation of notification messages (name, endpoint and function blocks) The spec defines that these notification only get sent upon receiving a Discovery message. Does this mean that the ALSA driver will poll at specific intervals to send a discover message or can the device send a notification even without a discovery message from the ALSA driver ? I could imagine a function block info / name, or endpoint info/ name or endpoint info change (i.e when the device changes the number of function block)
On Wed, 12 Jul 2023 15:26:15 +0200, Symbolic Debugger wrote: > > A question about the implementation of notification messages (name, endpoint and function blocks) > > The spec defines that these notification only get sent upon receiving a Discovery message. > > Does this mean that the ALSA driver will poll at specific intervals to send a discover message or can the device send a notification even without a discovery message from the ALSA driver ? I could imagine a function block info / name, or endpoint info/ name or endpoint info change (i.e when the device changes the number of function block) It's handled in ALSA UMP core code. It doesn't poll but just interprets each incoming UMP messages and responds to it (e.g. when a notification comes from the device, ALSA core will update the information accordingly to be visible to user-space). The change of FB info is indeed allowed by the device, AFAIK. And, this can notify via the corresponding UMP Stream messages. For example, reassigning UMP Groups in a FB is a valid scenario, and this will be informed via UMP Stream messages. For the FBs that will never change Groups, there is a "static blocks" flag (which was quite recently introduced). I guess most of devices mark this, as it's compatible with the former MIDI 2.0 USB devices. BTW, the USB MIDI 2.0 gadget function driver is under development. It's almost ready, and my plan is to submit likely for 6.6 kernel (that is, in the next week or so). You can find the patches in topic/midi20-gadget branch of my sound.git tree. Takashi