Hello Takashi, First of all, thank you for the feedback. To be honest, your suggestion to use the sequencer layer that is below the MIDI layer is very appealing to me. I would be able to use the sound subsystem as a transport layer without worrying of being compliant with the MIDI protocol: The Line6 Edit protocol is proprietary. Please find below my new questions. Be prepared, I am newbie with the ALSA subsystem ^^. - My understanding is that in [2], you are directly using the Linux firewire subsystem with your service from the userspace to parse or write events from/to the device before sending them to ALSA kernel subsystem. If i try to implement the same kind of process with libusb, within the userspace, I will be confronted to the fact that the device is already claimed(locked) by the kernel module snd-usb-podhd. If I read [3] it seems that such mechanism are not existing for firewire and therefore it is not possible to do the same with usb. Am I correct? - If I check /proc/asound/hwdep, I have "00-00: config". This seems to be more generic to ALSA subsystem than the audio/device module. In your architecture in [2], is the ALSA hwdep dedicated to your sound card or is it global to the ALSA subsystem? - Why using specifically a model "device<->firewire subsystem (kernel)<->service(userspace)<->alsa subsystem(kernel)<->application(userspace)" instead of something like "device<->firewire subsystem (kernel)<->service(userspace)<-pipe/unix socks->application(userspace)"? What are the pros and cons? Thanks in advance, Nicolas SCHWARTZ [3] https://www.kernel.org/doc/html/latest/driver-api/firewire.html > Hi, > > I'm a maintainer of ALSA firewire stack. > > On Tue, Jul 14, 2020 at 11:10:43PM +0200, Nicolas SCHWARTZ Aurryon wrote: >> I am looking to re implement and publish with the help of Wireshark a >> software like Line6 PODHD 500x Edit for my POD HD500X (modification of >> guitar pedal effects). To do this I need to claim the usb interface >> that is already used by the snd-usb-podhd and redo the initialisation, >> also already done by snd-usb-podhd. Therefore, to have both the audio >> and the pedal management I would need to modify the module mentioned >> above. This would aim to create a bridge between kernel and the >> userspace, that redirects the usb urb bulk requests that are not used >> by the audio part, to an interface (only isochronous is used after the >> init). >> >> In the objective to be merged upstream in the future, how should I >> proceed: >> * Use midi interfaces and create a fake one, knowing that the >> proprietary but readable protocol is not midi compliant? >> * Create a char device for the podhd pedal boards? Within the same >> module? >> * Other suggestions? > Firstly, I apologize to address an idea against the above objective. > > In my opinion, if the ALSA hwdep device named as 'config' is available > to receive the notification of pedal event in userspace application, you > have another option to implement service program in userspace. > > The service program convert the pedal event to ALSA Sequencer event (e.g. > snd_seq_ev_ctl_t[1]) and emit it to port. Another ALSA Sequencer > applications can receive the event via the port. > > Even if it's not available via the 'config' ALSA hedep device, it's > possible to add another ALSA hwdep device for your purpose. In this > case, you need knowledge about convention of ioctl command in Linux > kernel. > > For your information, recently I publish service program for audio and > music units on IEEE 1394 bus to implements the above idea[2]. If you > are interested, please refer to some illustrations in README.rst. > ("Listener model (with help of drivers in ALSA firewire stack)" is > similar to your case but it depicts the case of ALSA control. Not > depicted, I utilize ALSA sequencer in service program for TASCAM FireWire > series as well.) > > It's my pleasure if the above message is helpful to your work. > > > (I know users/developers are eager to put codes into kernel space. I have > no objection to itself. In a view of users, it's preferable because > all codes in the same place, but it requires some efforts for them; > e.g. write code for kernel land following to kernel code style, and > maintain vendor-specific codes following to development cycle of Linux > kernel. This is not so suitable in the case that the communication > protocol is got by reverse-engineering effort and the target devices > have slight differences in the protocol since modified code is not > so quickly published than the code in user space.) > >> In the same way, I am looking for suggestion regarding the data >> transmitted within this interface. Would something like struct {int >> message_len, char * data} be sufficient to be transmitted at every urb >> bulk request? >> >> Thanks in advance, >> >> Nicolas SCHWARTZ >> >> PS: I can share with you my test code and my current analysis on the >> messages sent/received by the pod when clicking on buttons/sending >> message from the PC, if needed. > [1] https://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__ev__ctrl__t.… > [2] https://github.com/alsa-project/snd-firewire-ctl-services > > > Cheers > > Takashi Sakamoto