15 Jul
2020
15 Jul
'20
4:27 p.m.
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.…
[2] https://github.com/alsa-project/snd-firewire-ctl-services
Cheers
Takashi Sakamoto