Hi,
On Sat, 19 Dec 2020 12:33:52 +0900
Takashi Sakamoto <o-takashi@xxxxxxxxxxxxx> wrote:
> Ah..., I've mentioned with the basis to use 'cset' instead of 'sset'
> since alsa-lib's simple mixer interface cannot handle control element
> with multiple values correctly.
>
> Amixer uses below APIs in simple mixer interface to compute
> dB-represented value:
> - snd_mixer_selem_set_playback_dB()
> - snd_mixer_selem_set_capture_dB()
>
> Thus it probably fails to operate control elements with 'sset'
> sub-commands for AF4.
I think I could finally understood the problem.
I only made a simple test with multiple integer values like below and thought my AF4 might be avoiding the problem. But my test was nonsense because it didn't return any information about the functions above. I think here is the time to give up the dB values. I don't have any skills to handle such a software developmental issue.
[~]$ amixer -c2 sset 'output-volume' 1,2,3,4,5,6
Simple mixer control 'output-volume',0
Capabilities: volume
Playback channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer
Capture channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer
Limits: 0 - 33554432
Front Left: 1 [0%]
Front Right: 2 [0%]Hi,
> > > In this August, I posted the series of patchset to update the content in
> > > firmware part only[1].
> > >
> > > [5] Not merged yet for several resons.
> > > [PATCH 00/25] alsa-tools: efw-downloader: add initial version of firmware
> > > downloader for Echo Audio Fireworks devices
> > > https://mailman.alsa-project.org/pipermail/alsa-devel/2020-August/172711.html
> >
> > It is good news for an AudioFire user like me, who has abondoned Windows for own use long ago.
> > I'll happily wait its release.
>
> I have a plan to push firmware files to linux firmware repository or so.
> But I have tasks with higher priority and it's postponed.
I understand.
I'm just glad that such a plan exists.
> > And nowadays should the user of pro-sumer firewire equipment, especially
> > who has little knowledge of Linux or ALSA like me, use FFADO than ALSA to
> > avoid troubles?
> >...
> Depends on your preference. It's my pleasure if you use ALSA drivers, but
> as I noted ALSA software support for multichannel devices is not enough
> good at present. If you have less motivations to ALSA project itself, it's
> better to use FFADO stuffs and leave ALSA software as is, as many users do.
After reading your explanation below, I could re-decided to keep using ALSA than FFADO.
Even though ALSA has some issues on my AF4, it is still more convenient than FFADO for me.
Thank you for the writing.
> > > At present, I leave them as is because the most of my time is used to
> > > develop the service programs and in-kernel packet streaming engine.
> >
> > ... I have no idea about "in-kernel packet streaming".
> > So please let me know about it and your works on it for my knowledge. If
> > it is convenient for my audio system, I'd also like to try them.
>
> Hm. I attempt to describe software relevant to audio and music units on
> IEEE 1394 bus.
>
> The most of devices in IEEE 1394 bus for use case of audio and music
> utilize isochronous communication. It looks like 'packet streaming'.
And 'in-kernel packet streaming engine' is a special mechanism of LINUX kernel to smoothly handle such a audio signal stream of firewire, and the development of this is your future work. This my understanding is right?
> On the other hand, drivers in ALSA firewire stack doesn't produce the
> way to control them since they are developed with focus on packet streaming.
> Service programs in 'snd-firewire-ctl-services' repository produces
> controls for the functionalities, as you tested.
And now any mixer apps of ALSA can control my AF4. So I can consider much more means to operate my AF4 in ALSA than FFADO.
Actually I've found a GUI mixer app, I mean QAMix[1], which seems to allow its user to define a custom control surface for one's own device with XML. I'll try to write the definition for my AF4.
[1] http://alsamodular.sourceforge.net
> Some users indicates that devices generates noisy sound when using
> drivers in ALSA firewire stack. On the other hand, they generates
> expected sound when using jackd with libffado2. I've been investigating
> the issue further for recent years with newly-developed tools (libhinawa
> and libhinoko) for analysis of packet streaming in several kinds of
> devices. After finishing development of the service programs, I'll tackle
> the issue (I guess next whole year).
It sounds good for me. I also hear too often clicking noise in combination of ALSA and Jack with Jack's default buffer size and I have to set the size 8 times long to eliminate the noise. I guess it is mainly caused by the poorness of my CPU. But I expect your the future work may lighten this.
> At last, if you find some issues of ALSA firewire stack, please file it in
> repository which I maintain[3]. If you find some issues of control service
> programs, please file it as well[4]. I'm pleased to see it.
I understand. But I'm afraid of making a useless comment for developers because I have few knowledge of software development and git. Are there any guide to post an useful report which is especially recommend to read for a non software developer like me?
> (I note that I should pay enough attention to whole supported devices,
> on the other hand users tend to focus just on their own device. The
> difference of each place can easily bring miscommunication.)
Yes. But what should the user be aware of to avoid such a communication failure?
I'd also like to be given any advice or suggests on it.
Regards,
Susie B.
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
