I have been playing with this repo and the results are actually quite good.
https://github.com/voice-engine/ec I have been using exactly the same parameters with the following. # The IPC key of dmix or dsnoop plugin must be unique # If 555555 or 666666 is used by other processes, use another one # use samplerate to resample as speexdsp resample is bad #defaults.pcm.rate_converter "samplerate" pcm.!default { type asym playback.pcm "playback" capture.pcm "echo" } pcm.playback { type plug slave.pcm "dmixed" } pcm.echo { type speex slave.pcm "agc" echo yes frames 128 filter_length 4096 } pcm.agc { type speex slave.pcm "capture" agc 1 } pcm.capture { type plug slave.pcm "array" route_policy sum } pcm.dmixed { type dmix slave.pcm "hw:seeed2micvoicec" ipc_key 555555 } pcm.array { type dsnoop slave { pcm "hw:seeed2micvoicec" channels 2 } ipc_key 666666 } I really don’t understand how the above repo can do such and excellent job and then with alsa-plugins it can provide zero EC and also vocode the recording so badly? Surely there is something wrong with the implementation? Its doesn’t make and sense unless I have the above asound.conf wrong? But https://github.com/voice-engine/ec works quite effectively? Stuart Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Peter P.<mailto:peterpar...@fastmail.com> Sent: 21 April 2020 21:51 To: alsa-user@lists.sourceforge.net<mailto:alsa-user@lists.sourceforge.net> Subject: Re: [Alsa-user] alsa-only applications (such as jitsi) via jackd * Peter P. <peterpar...@fastmail.com> [2020-04-21 20:20]: > * Clemens Ladisch via Alsa-user <alsa-user@lists.sourceforge.net> [2020-04-12 > 11:55]: > > Peter P. wrote: > > > Can I set pcm device names per application as defaults? > > > > If the application does not allow you to set the ALSA device name, > > you have to replace the device definition that the application used > > (probably "default"). > Thanks Clemens, just to make sure I get you right: Some applications do > not allow me to set "PCM devices" but only cards? In that case I can > only redefine default by changing/creating a .asoundrc? > > > It would be possible to create a device definition that reads an > > environment variable (the "hw" device does this with ALSA_PCM_*), > > but the "default" device does not do this. > I am just making my way through alsa terminology, let me ask you if you > mean a "PCM device" called hw, not the hw as a protocol for accessing > cards? I am replying to my last thread here to tell that I finally managed to make a non-jackified application (jitsi meet application image in my case) use jack. I did this by installing the libasound2-plugins Debian package, which provides a jack plugin for alsa. Then I created an .asoundrc with the below contents which points to the built-in soundcard hw:0 as a default, but permits any environment variable (ALSAPP for me) to change this assignment pcm.!default{ type plug slave.pcm { @func getenv vars [ ALSAPP ] default "hw:0" } } With jackd running I can now start any application prefixed with that variable pointing to the jack plugin $ ALSAPP=jack ffmuc-meet-x86_64.AppImage If anyone sees something I could improve here I'd be glad to know. Thanks for the help on this list! cheers, P _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
_______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
