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

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