Re: [LAD] [sound/usb/line6] Question on PODHD Edit features like implementation

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
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Jul 16 04:15:01 2020