[LAD] snd-firewire-ctl-services 0.1.0 released
Hi all, This is a short announcement about a new release of snd-firewire-ctl-services project. After development for mostly three years[1], version 0.1.0 is released today. If you have FireWire audio device and interests in ALSA support, the release would be worth to check out. * https://github.com/alsa-project/snd-firewire-ctl-services/releases/tag/snd-firewire-ctl-services%2Fv0.1.0 The project provides user space service programs to operate digital signal processing function in devices supported by ALSA firewire stack. If using such device, you can configure DSP functions such as the volumes of device. For some device, effects such as dynamics and equalizers are also configurable. Available devices are listed in README.rst of the project. The service programs work as 'message broaker'. ALSA control applications are available for end-user interface to communicate to the service programs[2]. The device connected to IEEE 1394 bus is the peer. The service programs receives messages from both ends, then translates and convert the messages to send to the opposite end. Against your expectation, the project provides neither GUI programs nor end-user interfaces. I know that the user experience is heavily on look-and-feel on the GUI programs, while it is out of the aim of project. I daily use quashctl in QasTools[3] and it is pretty good to me for such ALSA control application. If encountering any issue, please file it to github repository[4]. README should be helpful to new users. Thanks for your support and long patience to ALSA firewire stack. [1] https://lists.linuxaudio.org/hyperkitty/list/linux-audio-dev@lists.linuxaudio.org/thread/EX4FJ7IIRYM5EDRCYXFXFSABAKYZH3WZ/ [2] For TASCAM FireWire series, ALSA sequencer application is such end as well to operate control surface. [3] https://gitlab.com/sebholt/qastools [4] https://github.com/alsa-project/snd-firewire-ctl-services Regards Takashi Sakamoto ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] RFT: implementation for MOTU FireWire series including CueMix DSP and CueMix FX
ng issues * Please use issue service in github.com[10]. * Preferable issues * The service program aborts when I operate control A. * The service program doesn't interact with on-board operation B. * The service program looks to be frozen when I operate C. * The behaviour of control element D is odd. * Unexpected issues * Why device A is not supported * It's preferable for you to take your time to cooperate with me if you wish. It might take a long time since the implementation lays down user space and kernel space. * If so, please file the issue to my remote repository for kernel prepatch[12]. * Why we have no GUI with cool look and feel * It's your work. The GUI application might be an ALSA control application which interacts with the service program. * I can not get which control value corresponds to actual ports * It is restriction under current design of ALSA control interface. We need to work for any extension to the design. * The name of control B is not user-friendly. * The name of controls are not fixed yet since we have few name convention for controls in studio-use equipments. It might corresponds to discussion in ALSA upstream. In my opinion, Linux audio developers have been enough lazy to the issue for recent decade. [1] https://github.com/alsa-project/snd-firewire-ctl-services/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=66c6d1ef86ff [3] https://github.com/takaswie/snd-firewire-improve [4] https://github.com/alsa-project/alsa-gobject/ [5] https://lore.kernel.org/alsa-devel/20200623093239.GA68404@workstation/ [6[ https://github.com/alsa-project/libhinawa [7] https://github.com/alsa-project/libhinawa/tree/topic/motu-mixer-ioctl [8] https://github.com/alsa-project/snd-firewire-ctl-services/ [9] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/motu-mixer-ioctl [10] https://github.com/alsa-project/snd-firewire-ctl-services/issues [11] https://gitlab.com/sebholt/qastools [12] https://github.com/takaswie/snd-firewire-improve/issues [13] https://web.archive.org/web/20110704073441/http://subversion.ffado.org/browser/trunk/libffado/doc Cheers Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] New udev rules for firewire character device are added to systemd
Hi, Summary of this message: * systemd got udev rules with new database for firewire node/unit * then fw character device for audio is owned by 'audio' group with ACL * the entries are added by my investigation, thus doesn't cover all * if you have firewire audio devices not listed in README of below repository, please contact to me with image of configuration ROM: * https://github.com/takaswie/am-config-roms/ The way to create image file of configuration ROM is typically: ``` $ cat /sys/bus/firewire/devices/fw1/config_rom > filename.img ``` Here, I presuppose that Linux FireWire subsystem detects your device as 'fw1'. Well, in the past, access permission of Linux firewire character device is decided by udev rules just for video devices[1]. This was inconvenient some project such as ALSA and FFADO to produce audio application. The source code of libffado includes own file for udev rules[2] to take firewire character device owned by 'audio' group. Additionally the rules gives 'ID_FFADO' tag, and systemd includes another udev rule[3] to ACL at logging-in time according to it. As a whole, the above is not comprehensive and self-contained. I proposed patchset to systemd for better solution and today it was merged. * https://github.com/systemd/systemd/pull/19124 In the patchset, I add some udev rules, based on hwdb for new entries of node and units in IEEE 1394 bus. You can see the database[4]. The entries of database have below variables when matching to either node or unit devices: * IEEE1394_UNIT_FUNCTION_MIDI * IEEE1394_UNIT_FUNCTION_AUDIO * IEEE1394_UNIT_FUNCTION_VIDEO The added udev rules interpret the content of variables and decide group owner of fw character device(see [1]). Furthermore, the variables are used again to decide ACL in logging-in time(see [3], too). The entries of database also include below variables: * ID_VENDOR_FROM_DATABASE * ID_MODEL_FROM_DATABASE They are expected to use applications such as PipeWire and PulseAudio for better names of sound device, which binds to unit instead of node. I expect the variables can obsolete my former patch for pulseaudio[5]. I handy write the entries of database from my investigation, thus it could includes the lack of your device, or mistakes. I wish you to contact to me with image file of configuration ROM when you can not find your device in README of my collection repository[6], or when you find any mistakes in database file. Thanks for your cooperation in advance. [1] 4 rules in 'rules.d/50-udev-default.rules' https://github.com/systemd/systemd/blob/main/rules.d/50-udev-default.rules.in#L52 [2] many rules in 'libffado/60-ffado.rules' http://subversion.ffado.org/browser/trunk/libffado/libffado/60-ffado.rules?rev=2794 [3] 'src/login/70-uaccess.rules.m4' https://github.com/systemd/systemd/blob/main/src/login/70-uaccess.rules.m4 [4] 'hwdb.d/80-ieee1394-unit-function.hwdb' https://github.com/systemd/systemd/blob/main/hwdb.d/80-ieee1394-unit-function.hwdb [5] udev: use ID_MODEL/ID_VENDOR to give friendly name for FireWire devices https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/3ac73598c67c [6] https://github.com/takaswie/am-config-roms/ Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [RFT] ALSA control service programs for Fireworks board module
On Fri, Jul 24, 2020 at 10:37:35AM +0900, Takashi Sakamoto wrote: > On Thu, Jul 23, 2020 at 11:56:35AM -0700, Len Ovens wrote: > > On Thu, 23 Jul 2020, Takashi Sakamoto wrote: > > > > > > > > > > > $ cargo run --bin snd-fireworks-ctl-service 2 > > > > > > > > This worked great the first time, but after the next boot alsamixer > > > > showed a > > > > subset of the same controls (rather than no controls found) and I could > > > > not > > > > restart snd-fireworks-ctl-service. Is it expected that once the above > > > > > > I think that some users install system service for alsactl(1)[1]. In this > > > case, the system services add control element sets from cache file after > > > reboot. For the case the service program has a care to run with the > > > element > > > > That sounds like what I am seeing. Perhaps alsa-restore.service. I will try > > with that disabled. Yes that is the difference, it works as expected. I > > would guess this module would be added to alsa before alsa-restore.service > > after release. Restore would then be able to fix my clock settings. > > As long as I know, alsactl has some bugs to represent the content of > control element set in cache file. > > I guess you hit this bug since the feature called as user-define control > element set had not been used for a long time except for alsa-lib > 'softvol' PCM plugin. > > If alsactl worked expectedly, the order to execute the system service > for alsactl and the service program does not matter as long as they > don't run simultaneously. Oops. I overloop your demand to restore status of control element set automatically. I register an issue for this topic and queued for my future work: Restart alsa-restore.service after launching the service program https://github.com/alsa-project/snd-firewire-ctl-services/issues/9 Thanks Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [RFT] ALSA control service programs for Fireworks board module
On Thu, Jul 23, 2020 at 11:56:35AM -0700, Len Ovens wrote: > On Thu, 23 Jul 2020, Takashi Sakamoto wrote: > > > > > > > > $ cargo run --bin snd-fireworks-ctl-service 2 > > > > > > This worked great the first time, but after the next boot alsamixer > > > showed a > > > subset of the same controls (rather than no controls found) and I could > > > not > > > restart snd-fireworks-ctl-service. Is it expected that once the above > > > > I think that some users install system service for alsactl(1)[1]. In this > > case, the system services add control element sets from cache file after > > reboot. For the case the service program has a care to run with the element > > That sounds like what I am seeing. Perhaps alsa-restore.service. I will try > with that disabled. Yes that is the difference, it works as expected. I > would guess this module would be added to alsa before alsa-restore.service > after release. Restore would then be able to fix my clock settings. As long as I know, alsactl has some bugs to represent the content of control element set in cache file. I guess you hit this bug since the feature called as user-define control element set had not been used for a long time except for alsa-lib 'softvol' PCM plugin. If alsactl worked expectedly, the order to execute the system service for alsactl and the service program does not matter as long as they don't run simultaneously. > I have added comments to issues that are closed to indicate what I have > tested. The closed issues do seem to be fixed. I see your comments. Thanks for your help and patience! I merged the topic issue for this RFT into master now. Regards Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [RFT] ALSA control service programs for Fireworks board module
Hi Len, On Wed, Jul 22, 2020 at 09:40:01PM -0700, Len Ovens wrote: > On Sat, 18 Jul 2020, Takashi Sakamoto wrote: > > > This is request-for-test (RFT) to the ALSA control service programs for > > devices with Fireworks board module. The program is available in > > 'topic/service-for-efw' of below repository, and the RFT is corresponding > > to Pull Request #2: > ... > > If you have listed devices and handle them by ALSA fireworks driver, please > > test the service program according to the below instruction. > > > > * Mackie (Loud) Onyx 1200F > > * Mackie (Loud) Onyx 400F > > * Echo Audio Audiofire 12 (till Jul 2009) > > * Echo Audio Audiofire 8 (till Jul 2009) > > * Echo Audio Audiofire 12 (since Jul 2009) > > Audiofire12 (seems to have 4.8 firmware butbought used with no info) > > > > The project is written by Rust programming language[5] and packaged by > > cargo[6]. To build, just run below commands in the environment to connect > > to internet: > > > > ``` > > $ git clone https://github.com/alsa-project/snd-firewire-ctl-services.git > > -b topic/service-for-efw > > $ cd snd-firewire-ctl-services > > $ cargo build > > ``` > > ... > > > $ cargo run --bin snd-fireworks-ctl-service 2 > > This worked great the first time, but after the next boot alsamixer showed a > subset of the same controls (rather than no controls found) and I could not > restart snd-fireworks-ctl-service. Is it expected that once the above > command has been run once there are after effects? Is there a proper way to > install it so it runs from boot? Or is that already happening but perhaps > happening too soon before everything is settled? Hmm. The service program adds several control element sets to sound card at starting, and it deletes the added element sets when finishing. The system reboot is expected to have no effects since the added element sets are deleted at the same time the sound card is disonnected. I think that some users install system service for alsactl(1)[1]. In this case, the system services add control element sets from cache file after reboot. For the case the service program has a care to run with the element sets added by the system services. The care covers the case that the service program is terminated by the other signals than SIGTERM. It's possible to fail to start a new process for the service program when the old process still run because the service program holds ALSA hwdep character device exclusively. If the issue is certainly reproducible, I would request testers to mask the system services once, then run the service program. If the issue still occurs, run strace(1) to the service program and gather information to detect where and how the service program is blocked. > I understand this is just a test for something that will become more > permanent in the future. So I don't know what I should expect. I have a plan to add more service programs for audio and music units on IEEE 1394 bus, supported by drivers in ALSA firewire stack. At the same time, I have additional plan for system service program to listen to udev events, then launch and maintain the service programs. This RFT is a first step for the system service, which allows users to control devices without adding a batch of code to kernel land. As you know, current major tools with ALSA control API (e.g. amixer, alsamixer) need more integration for studio-purpose devices. The inconvenience mainly comes from alsa-lib mixer abstraction. Additionally, current implementation of ALSA core is the lack of some features. For example, it's convenient to add labels to each channel of element value. In next development period of Linux kernel, I'm going to post some patches to add the feature. It's better idea to develop new GUI applications similar to envy24control. However, in this time I focus on integration for amixer/alsamixer or the smixer abstraction, but I need more time for the work. Anyway, thanks for your report. I already found some bugs and added patches to fix them. The combination of the service programs and ALSA standard tools is not enough for user's satisfaction, but it means that more integration is required for ALSA in the area of recording equipment. [1] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/work Thanks Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [RFT] ALSA control service programs for Fireworks board module
iface=MIXER,name='playback-mute' numid=5,iface=MIXER,name='playback-solo' numid=3,iface=MIXER,name='playback-volume' numid=32,iface=MIXER,name='stream-playback-routing' ``` Access permissions for relevant character devices -- The executable manipulates below character devices to dispatch, and emit events from end to end. The '%u' is the numerical number of instance in each subsystem: * ALSA control character device (/dev/snd/controlC%u) * ALSA hwdep character device (/dev/snd/hwC%uD%u) * Linux firewire character device (/dev/fw%u) Feedback Any feedback is welcome. For questions, please use mailing list of alsa-devel or alsa-users[7]. For issues, please use service of github.com[8]. Issues -- The name of control elements are not fixed yet since the convention of name for element set is not clear yet for recording equipment. Users may feel inconvenience to which channel corresponds to which physical port. Furthermore, in the case that element set includes several elements, it's unclear that which element corresponds to which physical port as well. ALSA control core has no feature for the above issues at present. [1] https://github.com/alsa-project/snd-firewire-ctl-services [2] https://gitlab.gnome.org/GNOME/glib [3] https://github.com/alsa-project/alsa-gobject/ [4] https://github.com/alsa-project/libhinawa [5] https://www.rust-lang.org/ [6] https://doc.rust-lang.org/cargo/ [7] https://www.alsa-project.org/wiki/Mailing-lists [8] https://github.com/alsa-project/snd-firewire-ctl-services/issues Regards Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [sound/usb/line6] Question on PODHD Edit features like implementation
Hi, On Wed, Jul 15, 2020 at 02:27:01PM +0200, Aurryon SCHWARTZ wrote: > 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? You got things correctly. In Linux USB subsystem, any USB interface can be reserved for exclusive access by software procedure called as 'claim'. It is one of features in Linux USB subsystem and not included in USB standard itself, as long as I know. So the service program is written with the expectation that no driver reserved the target USB interface. If in-kernel driver is expected to reserve the target USB interface, we need to prepare another 'path' to transfer/receive data to/from the interface in userspace. For the path, ALSA hwdep interface is one of options. (I note that Linux FireWire subsystem has no feature corresponding to 'claim' in Linux USB subsystem. IEEE 1394 specification has similar procedure called as isochronous resource reservation. The reservation is done just for stream data such as the sequence of audio data frame, therefore any node on the bus can always request simple read/write operation to the other nodes.) > - 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? In a design of ALSA hwdep core, ALSA hwdep interface is a thin wrapper of `struct file_operation` for Linux character device: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/core/hwdep.c#n319 Actual implementation of ALSA hwdep device differs driver by driver. All of ALSA drivers don't necessarily add hwdep device to Linux system. For the case of drivers in ALSA firewire stack, all of supported ioctl command are exported to user space in a shape of UAPI header. In the header, you can see some common ioctl(2) command and model-specific commands and notifications: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/include/uapi/sound/firewire.h The drivers implement the above. For example of ALSA bebob driver, `sound/firewire/bebob/bebob_hwdep.c` implements it. https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/firewire/bebob/bebob_hwdep.c You can see slight different in `sound/firewire/fireworks/fireworks_hwdep.c`. It implements vendor-specific transaction: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/firewire/fireworks/fireworks_hwdep.c Actual implementation of the vendor-specific command/response is in the service program. > - 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? It depends on the case, but protocol is always important when using inter-process communication (IPC). For the latter model, we need to decide protocol between service and application by ourselves. For the former model, the protocol is already given as ALSA control interface or ALSA Sequencer interface. We already have many ALSA applications in user space; e.g. amixer(1), alsactl(1), alsamixer(1) as ALSA control application, aseqdump(1), aplaymidi(1) as ALSA sequencer application. I'd like to use them as 'frontend' for functionality. Usually any in-kernel driver works as 'backend' for the functionality, but ALSA control core and ALSA sequencer core allows any userspace applications transparently works as 'backend'. It's convenient to the case of ALSA firewire stack. Regards Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
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
Re: [LAD] Details about Mackie Control or Mackie Human User Interface
Hi Paul and Len, Thanks for your replies. On Jul 20 2015 22:41, Paul Davis wrote: > On Mon, Jul 20, 2015 at 9:33 AM, Takashi Sakamoto > wrote: > >> Well, are there some developers who have enough knowledgement about MIDI >> messaging rule for Mackie Control or Mackie Human User Interface(HUI)? > > not sure what you mean by "rule". I'm intimately familiar with both MCP and > HUI. Great. >> As long as I know, for these models, there're three types of the >> converter; usual MIDI messages such as Control Change (CC), Mackie >> Control and Mackie Human User Interface, while I have a little >> knowledgement about the latter two types. > > MCP and HUI both consist of "usual MIDI messages". > > There are a couple of sysex messages used for hand-shaking + > discovery; everything else is just normal CC and note messages. I also know the MCP and HUI is a combination of MIDI messages. What I concern about is the sequence. If the seeuqnce requires device drivers to keep state (i.e. current message has different meaning according to previous messages), I should have much work for it. In this meaning, I use the 'rule'. Well, when DAWs and devices successfully establish the 'hand-shaking', they must maintain the state, such as TCP? And in the 'discovery', devices must retrieve informations from DAWs? Furthermore, in the 'rule', transactions (a set of requests/responses) are used? On Jul 21 2015 01:25, Len Ovens wrote: > It is (as Paul has said) straight MIDI. The best guide I know of is the > "Logic Control User's Manual" from 2002. The MIDI implementation starts > on page 105. The only thing maybe a bit odd is that there are encoders > that use CC increment and decrement instead of straight values, but any > sw written for these surfaces is aware of it. It's noce, thanks. But the metering is one of my headaches... On Jul 21 2015 01:25, Len Ovens wrote: > You will note the use of pitchbend for levels. CC has only 127 values > which can give "zipper" artifacts. If using CC, the values need to be > mapped to DB per tick and/or have SW smoothing. The top 50db of the > range are most important. I think you mean that rough approximation fomula in acoustics engineering for human perception (i.e. ISO 226:2003). On 2015年07月21日 01:25, Len Ovens wrote: > You get to make up your own midi map is what it finally comes down to. > OSC might be a better option as the values can be floats and there is no > limit to number of controls (Midi has only 127 CCs and some of those are > reserved). Currently, ALSA middleware has no framework for Open Sound Control. It just has implementations for MIDI like messages. In this time, I use rawmidi interface for my purpose. The MIDI messages will be available for userspace applications to read from ALSA sequencer functionality. Thanks Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Details about Mackie Control or Mackie Human User Interface
Hi all, I'm a ALSA developer. I currently focus on developing sound drivers for devices on IEEE 1394 bus. In this developing period for Linux 4.3, I'm working for TASCAM FireWire series such as FW-1884 and FW-1082. Well, are there some developers who have enough knowledgement about MIDI messaging rule for Mackie Control or Mackie Human User Interface(HUI)? As long as investigating FW-1082 and FW-1884, these two models transfer control messages over IEEE 1394 isochronous packets, The shape of these messages is similar to bitmap. In detail, see my RFC on alsa-devel: [alsa-devel] [RFC][PATCH 26/37] ALSA: firewire-tascam: add MMAP support to show status and control message http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094817.html To enable userspace applications to handle these messages, a converter to MIDI messages is required, as Windows/OS X drivers did. In my original plan, I off-load this task to userspace driver applications by adding mmap(2)ed page. While, due to some reasons, it's better to implement the converter into kernel driver. As long as I know, for these models, there're three types of the converter; usual MIDI messages such as Control Change (CC), Mackie Control and Mackie Human User Interface, while I have a little knowledgement about the latter two types. For this occasion, I want to know the details. If a cost to implement one of these two types, I'll use it for the converter. Else, I use usual MIDI messages for my patchset to ALSA upstream. Thanks Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing: new ALSA driver for Digi 002/003 family
Hi, On Jun 29 2015 04:32, mindandsky wrote: The driver seems to work well for me on Ubuntu Studio. I can play tracks and they sound great. Thanks for your testing. I am trying to use the SPDIF input on my Digi 002r. How do I activate the SPDIF inputs? The mode switch for digital input interface between S/PDIF and ADAT is on 0xe11c of device registers. When it's 0x00, ADAT is enabled. Else, S/PDIF is enabled. Currently there's no plan for the driver to have control elements for this, because it's can be implemented in userspace. For this purpose, please develop your own application or use 'linux-firewire-utils', like. ./firewire-request /dev/fw1 write 0xe11c 0x0001 (S/PDIF) ./firewire-request /dev/fw1 write 0xe11c 0x (ADAT) By the way, now, the driver is drastically changed (and rename to snd-firewire-digi00x). If you have a rest of time, please test the current version under 'amdtp-variants' branch. https://github.com/takaswie/snd-firewire-improve/tree/amdtp-variants Regards Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing: new ALSA driver for Digi 002/003 family
Hi Damien, On Apr 02 2015 09:28, Damien Zammit wrote: On 02/04/15 09:41, Takashi Sakamoto wrote: Several issues are still remained: * When allocates 2 or more channel numbers for the device, after 15 to 20 seconds from playbacking, any PCM samples causes noisy sound. Then, all of LED on the front panel light. The streaming still continues correctly. I have not seen this behaviour with your latest driver, Takashi. I think you would see this if the midi quadlet is confused with the pcm quadlets and you feed audio data into the midi port. (I have seen this before) The channel is *not* PCM or MIDI, it's IEEE 1394 isochronous resource channels. I shouhd have mention about it, sorry. In short, when two or more devices are connected on the same IEEE 1394 bus, the driver may cause the issue (or not). * The actual effects of external clock source is not clear. When set the clock source is somewhat external, even if stopping the clock source, the device continues to sound PCM samples against my expectation. I have successfully tested the device with ADAT and SPDIF sync. When I connect external clock source to the SPDIF-in port and send 0xe118 1 the SPDIF led light turns on and the streaming now syncs to the new clock. A flashing Sync led means that the sample rates are mismatched and the sync is not working correctly. But sync works well when sample rates are matched. OK. My Digi 002 Rack has no LEDs to show current clock source, so I have no way to check the actual sync in my eyes. I request you to test stopping the supply of clock source during streaming. I expect the streaming is stopped suddenly, then PCM playback/capturing also stop. I tried 0x011c but I am not convinced that this is related to ADAT at all. I think it is a switch to select the mode of SPDIF between consumer and pro SPDIF modes? I am guessing here but SPDIF sync no longer works when I toggle the mode to 1, and it has no effect when I attach ADAT cable and sync to ADAT, then toggling the mode does nothing. In my Digi 002 Rack, it's a selector between S/PDIF or ADAT for optical input/output interfaces. If not in your Digi 003+, this seems to be model-dependent issue and I'll drop it from the driver (digi00x-proc.c). Regards Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Call for testing: new ALSA driver for Digi 002/003 family
Hi all, This is a call-for-testing of my new ALSA driver for Digidesign 002/003 family. If you have these devices, would you please test the driver with your devices and report your experience about it. Especially, I want you to test MIDI port for machine control, because developers have no 'console' models, just tested with 'rack' models. When installing and testing, please follow this instructions: https://github.com/takaswie/snd-firewire-improve Patchset was already posted to alsa-devel and confirmed to playback/capture PCM samples/MIDI messages by ALSA applications. [alsa-devel] [RFC v2][PATCH 00/11] digi00x: new driver for Digidesign 002/003 family http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/089708.html Several issues are still remained: * The port for MIDI machine control message is not tested yet, because 002/003 console model are required. * When allocates 2 or more channel numbers for the device, after 15 to 20 seconds from playbacking, any PCM samples causes noisy sound. Then, all of LED on the front panel light. The streaming still continues correctly. * The actual effects of external clock source is not clear. When set the clock source is somewhat external, even if stopping the clock source, the device continues to sound PCM samples against my expectation. * The meaning of asynchronous messages is unknown. This patchset adds a functionality to receive it in userspace. You can test it with updated libhinawa sample script. https://github.com/takaswie/libhinawa In my plan, this patchset will proposed for Linux 4.2. But these issues need to be clear till the merge-window. Regards Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing (final): ALSA driver for some firewire devices
Hi Matt, (May 06 2014 07:33), M Murdock wrote: Now... what can I do to help debug MIDI communication with the ProjectMix? This is an important feature for me as half of the hardware functionality is as a control surface. I'm not sure your ProjectMix I/O has this issue or not because this is my assumption from behaviour of Firewire 1814. Firewire 1814 and ProjectMix I/O are quite similar. So at first I ask you to confirm ProjectMix I/O really has this issue. If ProjectMix I/O has buffer overflow for MIDI messages, it transmits packets with discontinuity. ALSA driver can detect it and report it to syslog: kernel: [19757.225489] snd-bebob fw1.0: Detect discontinuity of CIP: E8 40 So please confirm to see such logs when sending much MIDI messages to your ProjectMix I/O. Thanks Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing (final): ALSA driver for some firewire devices
Hi Matt, (May 06 2014 03:21), M Murdock wrote: ffado-dbus-server.out <http://linux-audio.4202.n7.nabble.com/file/n90825/ffado-dbus-server.out> As long as I can see this log, 'ffado-mixer' correctly communicate with 'ffado-dbus-server'. *FFADO*: version.h shows "PACKAGE_VERSION 2.1.-2504" svn log --limit 1 shows: r2504 | jwoithe | 2014-05-03 08:57:38 -0400 (Sat, 03 May 2014) | 1 line README: some initial editting of device status information in preparation for the release of FFADO 2.2 OK. It's based on r2504. Currently we, FFADO developers parepare for new FFADO version and this revision includes related modification for README. *ALSA*: git diff HEAD^ HEAD shows the following diff --git a/sound/firewire/amdtp.c b/sound/firewire/amdtp.c index e573f25..29291e4 100644 --- a/sound/firewire/amdtp.c +++ b/sound/firewire/amdtp.c @@ -418,7 +418,7 @@ static void amdtp_write_s16(struct amdtp_stream *s, I expected you to run 'git show' and just show me commit hash. But according to the 'index' field in this output, I can see HEAD in your local repository is based on this: firewire-lib: Fix wrong label for 16 bits Raw Audio data https://github.com/takaswie/snd-firewire-improve/commit/72c569b8e604cfb6dda73bd07bd46207cf8e007f I can understand you work with recent sources. I followed your request for logging ffado-dbus-server output. Attached is the debug file captured with the following: ffado-dbus-server -v 6 &> /tmp/ffado-dbus-server.out I started ffado-mixer, played with most of the analoge input sliders, auxiliary sliders, output sliders, and muted/unmuted channels. I also manually adjusted some of the faders on the ProjectMix. The ffado-dbus-server was then killed. I was able to confirm that the headphone volume works through the ProjectMix hardware when listening to random noise. So in this time, ffado-mixer works fine. I think you failed because there were several processes of 'ffado-dbus-server'. Usually just one process can execute I/Os between devices so your 'ffado-mixer' communicated to one of these processes which cannot execute I/Os. I was able to record and to play back using aplay and arecord and the "plughw:ProjectMix" device. This is great! I didn't see any logs in syslog for ALSA. I admit that I don't know the difference between "hw:ProjectMix" and "plughw:ProjectMix". For instance, how should I start jackd (I use qjackctl). Should I use the alsa or firewire driver in qjackctl? Which device should I specify, hw:ProjectMix or plughw:ProjectMix? Use hw:ProjectMix for jackd. jackd can automatically adjust the number of PCM channels, on the other hand aplay/arecord can't. Simple mixer control 'Clock Source',0 Simple mixer control 'Digital Input Interface',0 Simple mixer control 'Digital Output Interface',0 Simple mixer control 'Sync Status',0 I was unable to find out where or how to change the PCM channels. alsamixer exposes options for clock source, digital input interface (S/PDIF or ADAT) and digital output interface (S/PDIF or ADAT). I thought the PCM interfaces would refer to the physical input and output channels (analogue streams) available on the ProjectMix. I meant the 'Digital Input Interface' and 'Digital Output Interface' as 'digital interfaces for input/output'. They're not 'PCM interface'. When you switch these controls between 'S/PDIF' and 'ADAT', you can see the differences of PCM channels which your jackd recognizes. I would like to test the MIDI functionality, but I believe my jackd configuration needs attention first. Insight into how to configure jackd properly would be much appreciated. Try to execute in terminal: $ jackd -r -d alsa -d hw:ProjectMix -r 48000 If your system is configured to authenticate your account for 'rtprio' priviledge, this line is also available: $ jackd -R -P 89 -d alsa -d hw:ProjectMix -r 48000 Regards Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing (final): ALSA driver for some firewire devices
Hi Matt, (May 05 2014 12:49), M Murdock wrote: I am testing your FFADO and ALSA drivers for a ProjectMix I/O. My goal is to get the hardware running in Ardour3 with both a firewire interface and MIDI controls working. I hope this is possible presently. My configuration: Ubuntu 14.04 (recently upgraded to get kernel 3.13 for your ALSA driver) Installed the 3.11 firewire ALSA driver and the latest SVN FFADO driver I have disabled PulseAudio as described Thanks for your trial. At first, I want to confirm which revision of codes you use. What is the latest commit in your local repository for ALSA drivers and which revision of FFADO you use? Firewire: Your ffado-mixer opens and recognizes the ProjectMix, but I am not able to see any reaction to the ffado-mixer sliders on the ProjectMix hardware. Please get logs and report it to me. The 'ffado-mixer' request 'ffado-dbus-server' process to execute I/O from/to devices. So what you do is to get logs from 'ffado-dbus-server'. Follow this instruction: 1. Close ffado-mixer 2. Open your favorite terminal 3. Kill processes of 'ffado-dbus-server' because 'ffado-mixer' starts the process with dbus help $ killall ffado-dbus-server 4. run ffado-dbus-server with verbose option $ ffado-dbus-server -v 6 5. run 'ffado-mixer' It doesn't matter to run it by GUI/CUI 6. read outputs from 'ffado-dbus-server' in the terminal ALSA: I installed the modules with dkms. ALSA appears to identify the ProjectMix but I am not able to route sound through aplay or arecord. I am not able to verify MIDI to or from the ProjectMix. In ALSA side, logs are output in /var/log/syslog. So If you have problems, please refer to the file. ProjectMix I/O (and Firewire 1814) can change its number of PCM channels according to which digital interfaces are selected for input/output. So unless you don't know the rule, 'plughw' instead of 'hw' will be your help. Like: aplay -D plughw:ProjectMix /dev/urandom arecord -D plughw:ProjectMix /dev/null If you want to switch digital interfaces for input/output, please use amixer/alsamixer: $ amixer -c 1 Simple mixer control 'Clock Source',0 Capabilities: enum Items: 'Internal with Digital Mute' 'Digital' 'Word Clock' 'Internal' Item0: 'Internal' Simple mixer control 'Digital Input Interface',0 Capabilities: enum Items: 'S/PDIF Optical' 'S/PDIF Coaxial' 'ADAT Optical' Item0: 'S/PDIF Coaxial' Simple mixer control 'Digital Output Interface',0 Capabilities: enum Items: 'S/PDIF Coaxial' 'ADAT Optical' Item0: 'S/PDIF Coaxial' Simple mixer control 'Sync Status',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] MIDI functionality may work but there is an issue for Firewire 1814. So I guess ProjectMix I/O also has this issue because these devices are similar. For this issue, please see '2.Data rate for MIDI substream' in this post: [alsa-devel] A Restriction and rest of issues for this patchsets http://mailman.alsa-project.org/pipermail/alsa-devel/2014-April/075912.html Finally, I reccomend you to subscribe/post ffado-devel because there are some testers and users of this device. https://lists.sourceforge.net/lists/listinfo/ffado-devel Regards Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing (final): ALSA driver for some firewire devices
Hi Daniel, I notice that I cannot help you without enough logs with which I can realize what happens. At lease, 'verbose' options for aplay/arecord, '#' nodes in /proc/asound/cardX and dmesg. Additionally, would you please add 'LANG=C' when you get output from software. I cannot read Spanish language... > hi, it does not work. Try in following steps: 1. $ arecord /tmp/test.wav -D hw:UFX1604 -c 16 (I expected you receive 'Available formats' output) 2. $ arecord /tmp/test.wav -D hw:UFX1604 -c 16 -f (here the format, maybe S32_LE) (I expected you receive 'rate is not accurate' output) 3. $ arecord /tmp/test.wav -D hw:UFX1604 -c 16 -f (the same above) -r (got rate) (I expected it will run correctly.) I hope you to do these test when killing pulseaudio. The way is here: https://wiki.ubuntu.com/PulseAudio/Log Regards Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing (final): ALSA driver for some firewire devices
> still no audio is captured, apparently... > this card has 16 inputs, maybe I should specify somehow which one > should be used? The aplay/arecord has 'D' option. This option is used to indicate PCM device. When you omit this option, 'default' PCM device is used. In system with PulseAudio, 'default' PCM device is set as input/output from/to PulseAudio. I guess you record from PulseAudio, not directly from your device. Would you test with 'D' option? Like: $ arecord -D hw:UFX1604 -c 16 -f S32_LE -r 44100 /tmp/test.wav Thanks Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing (final): ALSA driver for some firewire devices
Hi Daniel, > I tested it with: > play test.mp3 - OK > arecord -d 3 -c 2 -f cd -t wav x.wav RECORDING SILENCE (maybe there is > something else to configure on my card, but I haven't been able to > record any sound. trying individual channels as well as stereo output > settings). So your test shows: - PCM playback goes well - PCM capture don't goes well > In FW mode this command just hangs. Would you explain more detail? Thanks Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing (final): ALSA driver for some firewire devices
Hi, At first, I request you to send output from: /proc/asound/UFX1604/#clock /proc/asound/UFX1604/#firmware /proc/asound/UFX1604/#formation > but there are no controls in alsamixer, This is expected. My drivers basically have no ALSA control interface because it's just for PCM/MIDI functionality (we call it as 'streaming'). Currently developers in related projects follow this policy. If you need to control internal mixer, please join in FFADO project. So you can test my drivers with ALSA PCM applications like aplay/arecord, jackd and so on. > nor in pavucontrol. This is expected. Currently PulseAudio fails to detect devices which my drivers supports. So we need to load PulseAudio's ALSA sink/source modules manually. $ pactl load-module module-alsa-sink device=hw:UFX1604 $ pactl load-module module-alsa-source device=hw:UFX1604 See: [pulseaudio-discuss] 'Failed to find a working profile' for firewire sound devices http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-January/019685.html Regards Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Call for testing: ALSA driver for Fireworks/BeBoB based devices
Hi Maximilian, Thanks for your test and report. I cannot reproduce the bug which you reported, with: - Debian GNU/Linux 8 (jessie) - Linux kernel 3.12-1-amd64 - mplayer2 2.0-701-gd4c5b7f-2 - All of BeBoB devices which I have - $ mplay -ao alsa:device=hw=1 /usr/share/sounds/alsa/* I believe 'verbose' option for mplayer may help our debugging. Regards Takashi Sakamoto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Call for testing (final): ALSA driver for some firewire devices
Hi all, This is a final call for testing my ALSA drivers for some firewire devices. Please test my drivers if you have some devices listed in the end of this mail. Or please contact to me if you have some deviices listed as 'able to be supported'. About the way to install drivers, please refer to my previous post: [LAD] Call for testing: ALSA driver for Fireworks/BeBoB based devices http://lists.linuxaudio.org/pipermail/linux-audio-dev/2013-October/034344.html I've already posted my last RFC to alsa-devel. So this may be a final call. Please read my previous mail for testing. [alsa-devel] [RFC v3] [PATCH 00/52] Enhancement for support of firewire devices http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071820.html I have one request to you. Currently I'm preparing merge-request to ALSA. Then I want to add testers' name into the patches with 'Tested-By' field. Of cource, testers can reject it. Please inform me if you hope or not when reporting. [Currently supported devices] snd-bebob: * Edirol, FA-66 * Edirol, FA-101 * Presonus, FIREBOX * PreSonus, FP10 (former known as FIREPOD) * PreSonus, Inspire1394 * BridgeCo, RDAudio1 * BridgeCo, Audio5 * Mackie, Onyx 1220/1620/1640 (Firewire I/O Card) * Mackie, d.2 (Firewire Option) * Stanton, ScratchAmp * Tascam, IF-FW DM * Behringer, XENIX UFX 1204 * Behringer, XENIX UFX 1604 * Behringer, Digital Mixer X32 series (X-UF Card) * Apogee Electronics, Rosetta 200/400 (X-FireWire card) * Apogee Electronics, DA/AD/DD-16X (X-FireWire card) * Apogee Electronics, Ensemble * ESI, Quatafire610 * AcousticReality, eARMasterOne * CME, MatrixKFW * Phonic, Helix Board 12 MkII * Phonic, Helix Board 18 MkII * Phonic, Helix Board 24 MkII * Phonic, Helix Board 12 Universal/18 Universal/24 Universal * Lynx, Aurora 8/16 (LT-FW) * ICON, FireXon * PrismSound, Orpheus * PrismSound, ADA-8XR * TerraTec Electronic GmbH, PHASE 88 Rack FW * TerraTec Electronic GmbH, PHASE 24 FW * TerraTec Electronic GmbH, Phase X24 FW * TerraTec Electronic GmbH, EWS MIC2/MIC8 * Terratec Electronic GmbH, Aureon 7.1 Firewire * Yamaha, GO44 * YAMAHA, GO46 * Focusrite, SaffirePro 26 I/O * Focusrite, SaffirePro 10 I/O * Focusrite, Saffire(no label and LE) * M-Audio, Firewire 410 * M-Audio, Firewire Audiophile * M-Audio, Firewire Solo * M-Audio, Ozonic * M-Audio NRV10 * M-Audio, ProFireLightbridge * Firewire, 1814 * M-Audio, ProjectMix I/O snd-fireworks: * Mackie(Loud), Onyx 400F * Mackie(Loud), Onyx 1200F * Echo Audio, AudioFire2 * Echo Audio, AudioFire4 * Echo Audio, AudioFirePre8 * Echo Audio, AudioFire8 * Echo Audio, AudioFire12 * Gibson, Robot Interface Pack snd-oxfw: * Griffin, FireWave * Lacie FireWire Speakers * Behringer,F-Control Audio 202 * Mackie, Onyx-i series (former models) * Mackie, Onyx Satellite [IDs are unknown but able to be supported] snd-bebob: * Apogee, Mini-ME Firewire * Apogee, Mini-DAC Firewire * Behringer, F-Control Audio 1616 * Behringer, F-Control Audio 610 * Cakawalk, Sonar Power Studio 66 * CME, UF400e * ESI, Quotafire XL * Infrasonic, DewX * Infrasonic, Windy6 * Mackie, Digital X Bus x.200 * Mackie, Digital X Bus x.400 * Phonic, HB 12 * Phonic, HB 24 * Phonic, HB 18 * Phonic, FireFly 202 * Phonic, FireFly 302 * Rolf Spuler, Firewire Guitar snd-oxfw: * Mackie(Loud), d.2 pro * Mackie(Loud), d.4 pro * Mackie(Loud), U.420 * Mackie(Loud), U.420d * Mackie(Loud), Tapco Link.Firewire Regards Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Call for testing: ALSA driver for Fireworks/BeBoB based devices
Hi all, This is a call for testing my ALSA driver for Fireworks/BeBoB based devices. Please test 'snd-fireworks' for Fireworks and 'snd-bebob' for BeBoB if you have some devices listed in the end of this mail. Status: - still under development - Without snd-dice and Clemens' development (I must do this later) Functionality: - playback/capturing (full duplex) with PCM/MIDI interface - hardware metering for some devices with CONTROL interface - switching clock source/digital interface/digital mode with CONTROL interface - print hardware status with PROC interface Note: - Don't use simultaneously 'ALSA PCM/MIDI playback/capture' and 'jackd with Firewire (FFADO) backend'. Both of them try connecting to the device when another is running. - I add much modification into snd-firewire-lib for full duplex synchronization of receive/transmit AMDTP stream. Requirement: - Linux kernel 3.11 or later because of Juju (nickname of Firewire stack) changing its API. - Dynamic Kernel Module Support (DKMS) is reccomended for safely installing/uninstalling (I work with Ubuntu 13.10) Bug report: - report with /proc/asound/cardX/#XXX - please send your experiences to me with the output How to install (DKMS): 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git 2. $ ln -s $(pwd)/snd-firewire-improve/ /usr/src/alsa-firewire-3.11 (superuser) 3. $ dkms install snd-firewire/3.11 (superuser) How to uninstall (DKMS): 1. $ modprobe -r snd-bebob snd-fireworks snd-firewire-lib (superuser) 2. $ dkms remove ans-firewire/3.11 --all (superuser) 3. $ rm /usr/src/alsa-firewire-3.11 (superuser) 4. $ rm snd-firewire-improve How to install (Manual): 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git 2. $ cd snd-firewire-improve 3. $ make 4, backup system snd-firewire-lib/snd-firewire-speakers/snd-isight (superuser) 5. install snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) 6. depmod -a (superuser) How to uninstall (Manual) 1. modprobe -r snd-firewire-lib snd-firewire-speakers snd-isight snd-fireworks snd-bebob (superuser) 2. remove snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) 3. recover snd-firewire-lib/snd-firewire-speakers/snd-isight (superuser) 4. depmod -a (superuser) Confirmed to work: - AudioFire4 - AudioFirePre8 - Ozonic - Firewire Solo - Firewire Audiophile - Firewire 410 == Fireworks based devices [Echo Audio] AudioFire2 AudioFire4 AudioFirePre8 AudioFire8 (till 2009) AudioFire8 (since 2009) AudioFire12 [Gibson] RIP [Mackie] Onyx 400F Onyx 1200F == BeBoB based devices [Yamaha] GO44 GO46 [M-Audio] (to control mixer channels please use FFADO upstream) Ozonic Firewire 410 Firewire Audiophile Firewire Solo NRV10 ProFireLightbridge [Focusrite] SaffirePro 26 I/O SaffirePro 10 I/O Saffire(LE) [Edirol] FA-66 FA-101 [TerraTecElectronic GmbH] Phase88FW PhaseX24FW [PreSonus] FireBox FirePod [Mackie] OnyxFirewire [Tascam] IF-FW/DM [Behringer] X32 [ApogeeElectronics] Rosetta200 [ESI] Quatafire610 Regards Takashi Sakamoto o-taka...@sakamocchi.jp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
