Hello again, I am thinking too overcomplicated. The hwdep is already initialised and able to submit and receive data in the kernel module. So I don't need to modify anything which is great.
Thus I answered myself the two first questions. Best regards, Nicolas SCHWARTZ Le 15/07/2020 à 14:27, Aurryon SCHWARTZ a écrit : > 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.html >> [2] https://github.com/alsa-project/snd-firewire-ctl-services >> >> >> Cheers >> >> Takashi Sakamoto _______________________________________________ Linux-audio-dev mailing list [email protected] https://lists.linuxaudio.org/listinfo/linux-audio-dev
