15 Jul
2020
15 Jul
'20
6:07 a.m.
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