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
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. I have added comments to issues that are closed to indicate what I have tested. The closed issues do seem to be fixed. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] WIP, RFC: jack2_split
Hi Fons, thanks for your quick reply and insightful comments! On 7/23/20 2:16 PM, Fons Adriaensen wrote: A few comments: * Doesn't jack2 have this built-in ? I seem to remember something called 'loopback ports', but it has been some time... So you start jack2 with the required number of loopback ports, then connect A -> writable side of loopback ports, and readable side -> B. That would make some sense. I saw the --loopback option on jack2's commandline help, but didn't find it documented in the man page and always wondered about its semantics. When I wrote this little tool I completely forgot about --loopback though :) * Since this is just a buffer, the '-split' name seems a bit misleading. I didn't come up with a better name yet. I'll look into the loopback ports. If those do precisely what I want then looking for a better name is moot anywys. * I'm not convinced that the logic used in your current implementation will do the right thing in all cases (but I could be mistaken). I'm not convinced either SMP code is hard. But I *almost* convinced myself that with sequential consistency for both loads and stores it should work out. The reliable way to organise this would be to use a dummy port in reverse direction on both clients and connect those. OK.. Thanks again and regards, FPS -- https://fps.io ___ 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
Re: [LAD] WIP, RFC: jack2_split
On Thu, Jul 23, 2020 at 01:30:29PM +0200, Florian Paul Schmidt wrote: > jack2_split breaks the serial dependency by registering two jack clients > which respectively only have terminal input and output ports. It copies > the buffers from its inputs to its outputs after the current process > cycle. This introduces one additional period of latency into the graph, > but allows jack2/jackdmp to schedule A and B in parallel (e.g. on two > cores). A few comments: * Doesn't jack2 have this built-in ? I seem to remember something called 'loopback ports', but it has been some time... So you start jack2 with the required number of loopback ports, then connect A -> writable side of loopback ports, and readable side -> B. * Since this is just a buffer, the '-split' name seems a bit misleading. * I'm not convinced that the logic used in your current implementation will do the right thing in all cases (but I could be mistaken). The reliable way to organise this would be to use a dummy port in reverse direction on both clients and connect those. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] WIP, RFC: jack2_split
Hi, I had a hunch that's there is a way to trade latency for parallelism in serial jack graphs (at least on jack2/jackdmp setups). Comments welcome.. https://github.com/fps/jack2_split README.md below: jack2_split A program that facilitates parallelism in serial jack graphs by introducing latency. Only useful for jack2/jackdmp - it does nothing but add latency in jack1 setups. What? If you have a jack processsing graph that looks like this: capture -> A -> B -> playback where A and B are jack clients, then A and B must be scheduled in series due to the linear dependency. Running A and B serially might produce xruns (i.e. violate the scheduling deadline imposed by jackd) while running only A or only B might not. jack2_split can be used to remedy the situation by using the following graph: capture -> A -> jack2_split -> B playback jack2_split breaks the serial dependency by registering two jack clients which respectively only have terminal input and output ports. It copies the buffers from its inputs to its outputs after the current process cycle. This introduces one additional period of latency into the graph, but allows jack2/jackdmp to schedule A and B in parallel (e.g. on two cores). -- https://fps.io ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
