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

[Aurryon SCHWARTZ]

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