|
I think ARDOPCF uses "hw:1.0" and QtSoundModem does also.
May I 'unconfigure' my 'AX.25_A' modem in QtSoundModem and
configure ARDOPCF to use "hw:1,0 Channel_A" or similar in its place.
It would be very nice to be able to run AX.25, IL2P, and ARDOPCF
on one radio and 3 kHz band segment.
73, Chuck
|
You can run both ardopc(f) amd QtSoundModem at the same time. On Windows it is trivial, as Windows allows sharing a sound card. The Linux ALSA hw: driver does not let you share the same soundcard with multiple applications, but there are ALSA plugins DMIX and DSNOOP which will combine streams. Pulseaudo will also allow sharing, but has it own problems.
Configuring DMIX and DSNOOP can be a bit complicated, especially if your soundcard does not directly support a sample rate of 12000. I'm still trying to get it to work, but I'm pretty sure others have and hopefully will post their configurations.
73,
John
toggle quoted message
Show quoted text
On 07/06/2024 21:45, Chuck Gelm wrote: I think ARDOPCF uses "hw:1.0" and QtSoundModem does also.
May I 'unconfigure' my 'AX.25_A' modem in QtSoundModem and
configure ARDOPCF to use "hw:1,0 Channel_A" or similar in its place.
It would be very nice to be able to run AX.25, IL2P, and ARDOPCF
on one radio and 3 kHz band segment.
73, Chuck
|
On 6/8/24 04:14, John G8BPQ wrote:
Configuring DMIX and DSNOOP can be a bit complicated, especially
if your soundcard does not directly support a sample rate of
12000. I'm still trying to get it to work, but I'm pretty sure
others have and hopefully will post their configurations.
My -7 node is x64 bookworm and for some time now has 4 active
ports on the same 40m dial frequency 7101.3 USB. These all share
the same Signalink USB device at hw:0.0.
Port 5 is fx25 300b using the UZ7HO driver with QTSM port A and
center adjusted +1000, 7 is QPSK V26A 600b also using the UZ7HO
driver with QTSM port B and center adjusted +2000, 8 is VARA500
via wine and 9 is ARDOPC64 500MAX both at +1500 are smack dab in
between FX25 and V26A. The UZ7HO driver was used for ports 5 and 7
in order to support INTERLOCK in the port definitions which last I
knew was not supported with KISS.
The FX25 port handles both interactive connects and BBS forwards.
The V26A port sometimes shows a few callsigns in the MH list but
has so far not been used by anyone for anything other then me
occasionally testing. I expected this to be busier given some of
the chatter a while back about using V26A but at least for me
activity is very light here in EPA. Same thing with ARDOP 500MAX.
Other than my testing from the mobile in nearby parking lots and
such it is hardly used but it does work. The VARA500 port has thus
far been used by several for BBS forwards and works well for that.
I did not expect nor has there been any interactive use of that
port that I noticed.
I never had an issue with ardopc so although I saw the release
notice for ardopcf I have not tried it and cannot confirm it will
work with a configuration like mine. Anyway all that said a
configuration like this on x64 bookworm requires a $HOME/.asoundrc
file which can be complicated if unfamiliar and requires
corresponding adjustments in the wine registry for VARA. It also
requires a bit of CPU horsepower and although I do not use rPi
devices I've been told by others that tried similar configs as
above that rPi's are unable to do this much at once especially
where wine is required.
Anyway following is a sample $HOME/.asoundrc that works here:
pcm.SLUSB5 {
? type hw
? card 0
? device 0
}
pcm.SLUSB5_dsnoop {
? type dsnoop
? ipc_key 50001
? ipc_key_add_uid false
? ipc_perm 0666
? slave {
??? pcm "SLUSB5"
??? channels 1
??? rate 48000
? }
}
pcm.SLUSB5_dmix {
? type dmix
? ipc_key 60001
? ipc_key_add_uid false
? ipc_perm 0666
? slave {
??? pcm "SLUSB5"
??? channels 1
??? rate 48000
? }
}
pcm.SLUSB5_asym {
? type asym
? capture.pcm "plug:SLUSB5_dsnoop"
? playback.pcm "plug:SLUSB5_dmix"
}
Note that a "rate slave" block used to be required in a .asoundrc
for ardopc to work properly but a while back alsa updates enabled
removing it and using "rate 48000" within the slave section of the
dmix and dsnoop PCM's instead thereby simplifying the .asoundrc a
little. Note also that at least in my configuration that last
section for the asym required prefacing SLUSB5_dsnoop/dmix with
"plug:". It did not work well without it. And for wine to share
the Signalink for VARA with everything else required updating the
wine registry to make the asym available for use in s/w. Here is a
screenshot from the output of "wine regedit":
The ALSAInputDevices and ALSAOutputDevices must be created to
specify whatever name was chosen for the asym in $HOME/.asoundrc.
The QtSoundModem.ini file required manual edit to also use the
asym:
SndRXDeviceName=SLUSB5_asym
SndTXDeviceName=SLUSB5_asym
The ardopc64 specifies using SLUSB5_asym on the command line and
I run it within a wrapper that restarts it when s/w decides to
tell it to shutdown after using it.
And of course the Soundcard section of the VARA.ini file also
specifies:
Input Device Name=In: SLUSB5_asym
Output Device Name=Out: SLUSB5_asym
As usual with stuff like this YMMV but if it helps at all this is
what works for me.
73 de Rich WA3WLH
|
On 6/8/24 04:14, John G8BPQ wrote: You can run both ardopc(f) amd QtSoundModem at the same time. On Windows it is trivial, as Windows allows sharing a sound card. The Linux ALSA hw: driver does not let you share the same soundcard with multiple applications, but there are ALSA plugins DMIX and DSNOOP which will combine streams. Pulseaudo will also allow sharing, but has it own problems.
Configuring DMIX and DSNOOP can be a bit complicated, especially if your soundcard does not directly support a sample rate of 12000. I'm still trying to get it to work, but I'm pretty sure others have and hopefully will post their configurations.
73,
John Hi, John: Thanks. All/any: I have QtSoundModem running on a mini-laptop with: pi@nc8q-qj:~$ cat /etc/os-release NAME="Linux Mint" VERSION="21.1 (Vera)" ID=linuxmint ID_LIKE="ubuntu debian" PRETTY_NAME="Linux Mint 21.1" VERSION_ID="21.1" HOME_URL=" SUPPORT_URL=" BUG_REPORT_URL=" PRIVACY_POLICY_URL=" VERSION_CODENAME=vera UBUNTU_CODENAME=jammy Which uses the serial IO of an IC-7100 on 40 or 20 meters. QtSoundModem runs 300bd;(2) AX.25 and (2) IL2P modems, each on separate audio sub-bands. IOW, While there might be others using 7103.3c kHz AX.25, I can forward/receive on 7104.3c IL2P without interfering. QtSoundModem and pilinBPQ share an AREDN node for LAN/DHCP. So, in addition to HF ports, it is connected to a local SHF network of 30+ nodes. I need to read-up on DMIX and DSNOOP. If there are instructions leading to how to run QtSoundModem and ARDOPCF on an IC-7100, please tell me where. 73, Chuck
|
I'm currently testing ardopcf and QtSoundModem with an IC7100 on a Pi4.
I had to make a change to ardopcf to get it to open the dsnoop device (it reported can't set sample rate).
Once I'm happy that is it working I'll publish the patch to ardopcf and the ALSA configuration. It may not be for a few days as I'm away sailing at the moment.
73, John
toggle quoted message
Show quoted text
On 08/06/2024 18:48, Chuck Gelm wrote:
On 6/8/24 04:14, John G8BPQ wrote:
You can run both ardopc(f) amd QtSoundModem at the same time. On Windows it is trivial, as Windows allows sharing a sound card. The Linux ALSA hw: driver does not let you share the same soundcard with multiple applications, but there are ALSA plugins DMIX and DSNOOP which will combine streams. Pulseaudo will also allow sharing, but has it own problems.
Configuring DMIX and DSNOOP can be a bit complicated, especially if your soundcard does not directly support a sample rate of 12000. I'm still trying to get it to work, but I'm pretty sure others have and hopefully will post their configurations.
73,
John Hi, John:
Thanks.
All/any:
I have QtSoundModem running on a mini-laptop with:
pi@nc8q-qj:~$ cat /etc/os-release
NAME="Linux Mint"
VERSION="21.1 (Vera)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21.1"
VERSION_ID="21.1"
HOME_URL="
SUPPORT_URL="
BUG_REPORT_URL="
PRIVACY_POLICY_URL="
VERSION_CODENAME=vera
UBUNTU_CODENAME=jammy
Which uses the serial IO of an IC-7100 on 40 or 20 meters.
QtSoundModem runs 300bd;(2) AX.25 and (2) IL2P modems, each on separate audio sub-bands.
IOW, While there might be others using 7103.3c kHz AX.25, I can forward/receive on 7104.3c IL2P
without interfering.
QtSoundModem and pilinBPQ share an AREDN node for LAN/DHCP.
So, in addition to HF ports, it is connected to a local SHF network of 30+ nodes.
I need to read-up on DMIX and DSNOOP.
If there are instructions leading to how to run QtSoundModem and ARDOPCF on an IC-7100,
please tell me where.
73, Chuck
|
On 6/8/24 14:36, John G8BPQ wrote: I'm currently testing ardopcf and QtSoundModem with an IC7100 on a Pi4.
I had to make a change to ardopcf to get it to open the dsnoop device (it reported can't set sample rate).
Once I'm happy that is it working I'll publish the patch to ardopcf and the ALSA configuration. It may not be for a few days as I'm away sailing at the moment.
73, John Wow! I am loving this progress. :-) 73, Chuck
|
Hi, John:
Marvelous. There is a chance.
73, Chuck
toggle quoted message
Show quoted text
On 6/8/24 04:14, John G8BPQ wrote: You can run both ardopc(f) amd QtSoundModem at the same time. On Windows it is trivial, as Windows allows sharing a sound card. The Linux ALSA hw: driver does not let you share the same soundcard with multiple applications, but there are ALSA plugins DMIX and DSNOOP which will combine streams. Pulseaudo will also allow sharing, but has it own problems.
Configuring DMIX and DSNOOP can be a bit complicated, especially if your soundcard does not directly support a sample rate of 12000. I'm still trying to get it to work, but I'm pretty sure others have and hopefully will post their configurations.
73,
John
On 07/06/2024 21:45, Chuck Gelm wrote:
I think ARDOPCF uses "hw:1.0" and QtSoundModem does also.
May I 'unconfigure' my 'AX.25_A' modem in QtSoundModem and
configure ARDOPCF to use "hw:1,0 Channel_A" or similar in its place.
It would be very nice to be able to run AX.25, IL2P, and ARDOPCF
on one radio and 3 kHz band segment.
73, Chuck
|
On 6/8/24 14:36, John G8BPQ wrote: I'm currently testing ardopcf and QtSoundModem with an IC7100 on a Pi4.
I had to make a change to ardopcf to get it to open the dsnoop device (it reported can't set sample rate).
Once I'm happy that is it working I'll publish the patch to ardopcf and the ALSA configuration. It may not be for a few days as I'm away sailing at the moment.
73, John Does anyone have an update on running ARDOPCF and QtSoundModem on the same radio with linbpq? I would like to add ARDOPCF without loosing FX/AX.25 or IL2P. I am currently running QtSoundModem64 on a micro-laptop with NAME="Linux Mint" VERSION="21.1 (Vera)" ID=linuxmint ID_LIKE="ubuntu debian" PRETTY_NAME="Linux Mint 21.1" VERSION_ID="21.1" 73, Chuck
|
I'm using the following in .asoundrc. There are probably other configs that would work, but this works for me, with an IC7100.
If you use this format for the name of the plug devices (mixnn and snoop nn) the latest QtSM can be set to display these in the soundcard selection boxes.
73, John
pcm.dmix02 {
??? type dmix
??? ipc_key 60500
??? ipc_key_add_uid false?? # let multiple users share
??? ipc_perm 0666?????????? # IPC permissions for multi-user sharing (octal, default 0600)
??? slave {pcm "hw:2,0"}
}
pcm.dsnoop02 {
??? type dsnoop
??? ipc_key 5001
??? ipc_key_add_uid false?? # let multiple users share
??? ipc_perm 0666?????????? # IPC permissions for multi-user sharing (octal, default 0600)
??? slave {pcm "hw:2,0"}
}
# We need to define a plug linked to our dmix/dsnoop devices to do the rate conversion to 12000
pcm.mix02 {
??? type plug
??? slave.pcm "dmix02" # use our new PCM here
??? hint.description "Mix for hw:2,0"}
pcm.snoop02 {
??? type plug
??? slave.pcm "dsnoop02" # use our new PCM here
??? hint.description "Snoop for hw:2,0"}
toggle quoted message
Show quoted text
On 21/07/2024 21:40, Chuck Gelm wrote: On 6/8/24 14:36, John G8BPQ wrote:
I'm currently testing ardopcf and QtSoundModem with an IC7100 on a Pi4.
I had to make a change to ardopcf to get it to open the dsnoop device (it reported can't set sample rate).
Once I'm happy that is it working I'll publish the patch to ardopcf and the ALSA configuration. It may not be for a few days as I'm away sailing at the moment.
73, John Does anyone have an update on running ARDOPCF and QtSoundModem on the same radio with linbpq?
I would like to add ARDOPCF without loosing FX/AX.25 or IL2P.
I am currently running QtSoundModem64 on a micro-laptop with
NAME="Linux Mint"
VERSION="21.1 (Vera)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21.1"
VERSION_ID="21.1"
73, Chuck
|
Wondering if anyone can help with my configuration to get VARA HF and QTSoundmodem to share a sound device.? I tried the John G8BPQ's .asoundrc config and only changed it for my hw:1,0 sound device since that's the device I need QTSoundmodem and VARA HF to share on my my Linux Mint machine.? Dmix and dsnoop are both installed.? But I can't get the sound device to share between VARA HF and QTSoundmodem.? They will each use the soundcard fine by themselves, but not when they are running simultaneously.? QTSoundmodem shows "hw:1,0" in its dropdown menu, which is the correct soundcard.?? Here's what running the QtSoundModem64 returns, , and below that is my /asoundrc file:
?
Playback Devices
Card 0, ID `PCH', name `HDA Intel PCH'
? Device hw:0,0 ID `CX8200 Analog', name `CX8200 Analog', 1 subdevices (1 available)
? ? 2 channels, ?sampling rate 48000..192000 Hz
? Device hw:0,3 ID `HDMI 0', name `HDMI 0', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,7 ID `HDMI 1', name `HDMI 1', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,8 ID `HDMI 2', name `HDMI 2', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,9 ID `HDMI 3', name `HDMI 3', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,10 ID `HDMI 4', name `HDMI 4', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
Card 1, ID `HF', name `C-Media USB Headphone Set'
? Device hw:1,0 ID `USB Audio', name `USB Audio', 1 subdevices (0 available)
Error -16 opening output device
Card 2, ID `Device', name `C-Media USB Audio Device'
? Device hw:2,0 ID `USB Audio', name `USB Audio', 1 subdevices (0 available)
Error -16 opening output device
Card 3, ID `VHF', name `C-Media USB Audio Device'
? Device hw:3,0 ID `USB Audio', name `USB Audio', 1 subdevices (0 available)
Error -16 opening output device
Card 4, ID `Device_2', name `C-Media USB Audio Device'
? Device hw:4,0 ID `USB Audio', name `USB Audio', 1 subdevices (0 available)
Error -16 opening output device
Opening Playback Device hw:1,0 USB Audio(C-Media USB Headphone Set) Rate 12000
Real Device plughw:1,0
cannot open playback audio device plughw:1,0 (Device or resource busy)
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 1423, resource id: 9917682, major code: 40 (TranslateCoords), minor code: 0
?
And my .asoundrc contents:
?
pcm.dmix02 {
? ? type dmix
? ? ipc_key 60500
? ? ipc_key_add_uid true ? # let multiple users share
? ? ipc_perm 0666 ? ? ? ? ? # IPC permissions for multi-user sharing (octal, default 0600)
? ? slave {pcm "hw:1,0"}
}
pcm.dsnoop02 {
? ? type dsnoop
? ? ipc_key 5001
? ? ipc_key_add_uid true ? # let multiple users share
? ? ipc_perm 0666 ? ? ? ? ? # IPC permissions for multi-user sharing (octal, default 0600)
? ? slave {pcm "hw:1,0"}
}
# We need to define a plug linked to our dmix/dsnoop devices to do the rate conversion to 12000
pcm.mix02 {
? ? type plug
? ? slave.pcm "dmix02" # use our new PCM here
? ? hint.description "Mix for hw:1,0"}
pcm.snoop02 {
? ? type plug
? ? slave.pcm "dsnoop02" # use our new PCM here
? ? hint.description "Snoop for hw:1,0"}
?
?
?
?
?
?
|
Jeff
You need to point it to the dmix / dsnoop devices not the HW card. They are the virtual cards that can share.
73 Steve?
Wondering if anyone can help with my configuration to get VARA HF and QTSoundmodem to share a sound device.? I tried the John G8BPQ's .asoundrc config and only changed it for my hw:1,0 sound device since that's the device I need QTSoundmodem and VARA HF to share on my my Linux Mint machine.? Dmix and dsnoop are both installed.? But I can't get the sound device to share between VARA HF and QTSoundmodem.? They will each use the soundcard fine by themselves, but not when they are running simultaneously.? QTSoundmodem shows "hw:1,0" in its dropdown menu, which is the correct soundcard.?? Here's what running the QtSoundModem64 returns, , and below that is my /asoundrc file:
?
Playback Devices
Card 0, ID `PCH', name `HDA Intel PCH'
? Device hw:0,0 ID `CX8200 Analog', name `CX8200 Analog', 1 subdevices (1 available)
? ? 2 channels, ?sampling rate 48000..192000 Hz
? Device hw:0,3 ID `HDMI 0', name `HDMI 0', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,7 ID `HDMI 1', name `HDMI 1', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,8 ID `HDMI 2', name `HDMI 2', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,9 ID `HDMI 3', name `HDMI 3', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,10 ID `HDMI 4', name `HDMI 4', 1 subdevices (1 available)
? ? 2..8 channels, sampling rate 32000..192000 Hz
Card 1, ID `HF', name `C-Media USB Headphone Set'
? Device hw:1,0 ID `USB Audio', name `USB Audio', 1 subdevices (0 available)
Error -16 opening output device
Card 2, ID `Device', name `C-Media USB Audio Device'
? Device hw:2,0 ID `USB Audio', name `USB Audio', 1 subdevices (0 available)
Error -16 opening output device
Card 3, ID `VHF', name `C-Media USB Audio Device'
? Device hw:3,0 ID `USB Audio', name `USB Audio', 1 subdevices (0 available)
Error -16 opening output device
Card 4, ID `Device_2', name `C-Media USB Audio Device'
? Device hw:4,0 ID `USB Audio', name `USB Audio', 1 subdevices (0 available)
Error -16 opening output device
Opening Playback Device hw:1,0 USB Audio(C-Media USB Headphone Set) Rate 12000
Real Device plughw:1,0
cannot open playback audio device plughw:1,0 (Device or resource busy)
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 1423, resource id: 9917682, major code: 40 (TranslateCoords), minor code: 0
?
And my .asoundrc contents:
?
pcm.dmix02 {
? ? type dmix
? ? ipc_key 60500
? ? ipc_key_add_uid true ? # let multiple users share
? ? ipc_perm 0666 ? ? ? ? ? # IPC permissions for multi-user sharing (octal, default 0600)
? ? slave {pcm "hw:1,0"}
}
pcm.dsnoop02 {
? ? type dsnoop
? ? ipc_key 5001
? ? ipc_key_add_uid true ? # let multiple users share
? ? ipc_perm 0666 ? ? ? ? ? # IPC permissions for multi-user sharing (octal, default 0600)
? ? slave {pcm "hw:1,0"}
}
# We need to define a plug linked to our dmix/dsnoop devices to do the rate conversion to 12000
pcm.mix02 {
? ? type plug
? ? slave.pcm "dmix02" # use our new PCM here
? ? hint.description "Mix for hw:1,0"}
pcm.snoop02 {
? ? type plug
? ? slave.pcm "dsnoop02" # use our new PCM here
? ? hint.description "Snoop for hw:1,0"}
?
?
?
?
?
?
|
Hi John et al,
Although I've had no issues for several years using your ardopc both x86 and x64 I finally got around to testing with ardopcf for no good reason other than to busy myself for a few hours given the claim of many bug fixes... which led me to this thread from back in July.
I am so far only able to make ardopcf work by dedicating the ALSA audio device. Everything else I try including completely replacing the .asoundrc here with dmix, dsnoop, and plug entries as in your example all fail complaining about something called the playback "period size". I even tried specifying multiple combinations of periods, period_time, buffer_time, period_size, and buffer_size in the .asoundrc to no avail.
So before getting into any details I should mention I have no inclination to change what works and your ardopc / ardopc64 work fine here with no problem sharing the audio device via dsnoop and dmix. I am posting this mostly to ask if you or others in the group have been able to make ardopcf share the audio device on x86 / x64 systems (I think the initial thread was for rPi's which I do not use here) and more importantly if the claim of many bugs being fixed in ardopcf make it worthwhile to switch from ardopc(64) assuming it can be made to share audio. Otherwise not experiencing any "bugs" in ardopc(64) here I may as well just leave things alone.
There are FWIW some limited details below.
73 de Rich WA3WLH
Here is an example of how I use your ardopc64 and share the audio without issue using my .asoundrc:
./ardopc64 8515 IC7700_asym IC7700_asym
ardopc Version 1.0.4.1mBPQ-Debug5
-SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device IC7700_asym Rate 12000
Opening Capture Device IC7700_asym Rate 12000
ardopc listening on port 8515
Yet using ardopcf with the same .asoundrc fails:
./ardopcf_amd64_Linux_64 8515 IC7700_asym IC7700_asym
ardopcf Version 1.0.4.1.3 ()
- SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device IC7700_asym Rate 12000
cannot set playback period size (Invalid argument)
Error in InitSound().? Stopping ardop.
And finally here is an example of trying ardopcf using a .asoundrc the includes only what is in your example and edited to change from hw card 2 to 1:
./ardopcf_amd64_Linux_64 8515 snoop02 mix02
ardopcf Version 1.0.4.1.3 ()
-SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device mix02 Rate 12000
cannot set playback period size (Invalid argument)
Error in InitSound().? Stopping ardop.
|
You need to add the -A parameter to the ardopcf command line. Even with this I can't get the latest version to work and am currently using ardop-1.0.4.1.2. The error message is different (if I remember correctly is to to with sample rate).
Even with the older version another ham couldn't get it to work, and had use my binary.? I run on a 64 bit Pi.
I've had a look at the source changes between ardop-1.0.4.1.2 and the latest but haven't so far found what has changed. When I have a bit more time I'll investigate further.
73,
John
toggle quoted message
Show quoted text
On 02/01/2025 22:18, Rich Sahlender via groups.io wrote: Hi John et al,
Although I've had no issues for several years using your ardopc both x86 and x64 I finally got around to testing with ardopcf for no good reason other than to busy myself for a few hours given the claim of many bug fixes... which led me to this thread from back in July.
I am so far only able to make ardopcf work by dedicating the ALSA audio device. Everything else I try including completely replacing the .asoundrc here with dmix, dsnoop, and plug entries as in your example all fail complaining about something called the playback "period size". I even tried specifying multiple combinations of periods, period_time, buffer_time, period_size, and buffer_size in the .asoundrc to no avail.
So before getting into any details I should mention I have no inclination to change what works and your ardopc / ardopc64 work fine here with no problem sharing the audio device via dsnoop and dmix. I am posting this mostly to ask if you or others in the group have been able to make ardopcf share the audio device on x86 / x64 systems (I think the initial thread was for rPi's which I do not use here) and more importantly if the claim of many bugs being fixed in ardopcf make it worthwhile to switch from ardopc(64) assuming it can be made to share audio. Otherwise not experiencing any "bugs" in ardopc(64) here I may as well just leave things alone.
There are FWIW some limited details below.
73 de Rich WA3WLH
Here is an example of how I use your ardopc64 and share the audio without issue using my .asoundrc:
./ardopc64 8515 IC7700_asym IC7700_asym
ardopc Version 1.0.4.1mBPQ-Debug5
-SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device IC7700_asym Rate 12000
Opening Capture Device IC7700_asym Rate 12000
ardopc listening on port 8515
Yet using ardopcf with the same .asoundrc fails:
./ardopcf_amd64_Linux_64 8515 IC7700_asym IC7700_asym
ardopcf Version 1.0.4.1.3 ()
- SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device IC7700_asym Rate 12000
cannot set playback period size (Invalid argument)
Error in InitSound().? Stopping ardop.
And finally here is an example of trying ardopcf using a .asoundrc the includes only what is in your example and edited to change from hw card 2 to 1:
./ardopcf_amd64_Linux_64 8515 snoop02 mix02
ardopcf Version 1.0.4.1.3 ()
-SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device mix02 Rate 12000
cannot set playback period size (Invalid argument)
Error in InitSound().? Stopping ardop.
|
Hi Rich, same problem here...
What I have...
.asoundrc
pcm.snd_card {
??????? type hw
??????? card 0
??????? device 0
}
ctl.snd_card {
??????? type hw
??????? card 0
??????? device 0
}
pcm.dmixer {
??? type dmix
??? ipc_key 1024
??? ipc_perm 0666?????? # Other users can also use dmix at the
same time
??? slave.pcm "snd_card"
??? slave {
??????? period_time 0
??????? period_size 1024
??????? buffer_size 4096
??????? channels 2
??? }
??? bindings {
??????? 0 0
??????? 1 1
??? }
}
# The dsnoop plugin, which allows you to record multiple programs
at the same time.
pcm.dsnooper {
??? type dsnoop
??? ipc_key 2048
??? ipc_perm 0666
??? slave.pcm "snd_card"
??? slave
??? {
??????? period_time 0
??????? period_size 1024
??????? buffer_size 4096
??????? channels 2
??? }
??? bindings {
??????? 0 0
??????? 1 1
??? }
}
pcm.ardopin {type rate slave {pcm "plug:dsnooper" rate 48000}}
pcm.ardopout {type rate slave {pcm "plug:dmixer" rate 48000}}
pcm.asymwine {
??????? type asym
??????? playback.pcm "ardopout"
??????? capture.pcm "ardopin"
}
# make a default plug for it
pcm.!default {
??????? type plug
??????? slave.pcm "asymwine"
}
# define a plug for /dev/dsp
pcm.dsp {
??????? type plug
??????? slave.pcm "asymwine"
}
I can run QtSoundModem just fine with plug:dsnooper and
plug:dmixer or plug:ardopin and plug:ardopout.
Opening Playback Device plug:ardopout Rate 12000
Real Device plug:ardopout
Play using 2 channels
Playback Buffer Size 1024
Opening Capture Device plug:ardopin Rate 12000
Real Device plug:ardopin
Record channel count set to 2
Capture using 2 channels
InitSound :ardopin :ardopout
Input peaks = -3905, 5005
Input peaks = -5162, 7286
Input peaks = -5755, 5354
Input peaks = -4943, 6005
Input peaks = -4785, 7166
Opening Playback Device plug:dmixer Rate 12000
Real Device plug:dmixer
Play using 2 channels
Playback Buffer Size 1024
Opening Capture Device plug:dsnooper Rate 12000
Real Device plug:dsnooper
Record channel count set to 2
Capture using 2 channels
InitSound plug:dsnooper plug:dmixer
Input peaks = -4187, 5763
Input peaks = -4433, 5210
Input peaks = -5048, 5448
Input peaks = -32768, 32767
Input peaks = -4869, 6892
But ardopcf can`t set the sample rate.... (fist shutdown
QtSoundModem)
d9q@linux:~/ardop$ ./ardopcf-412 8515 plug:ardopin plug:ardopout
-A -G 8514
ardopcf Version 1.0.4.1.2 ()
Copyright (c) 2014-2024 Rick Muething, John Wiseman, Peter LaRue
See for
licence details including
? information about authors of external libraries used and their
licenses.
ARDOPC listening on port 8515
Capture Devices
Card 0, ID `PCH', name `HDA Intel PCH'
? Device hw:0,0 ID `ALC3234 Analog', name `ALC3234 Analog', 1
subdevices (1 available)
??? 2 channels,? sampling rate 44100..192000 Hz
? Device hw:0,2 ID `ALC3234 Alt Analog', name `ALC3234 Alt
Analog', 1 subdevices (1 available)
??? 2 channels,? sampling rate 44100..192000 Hz
Playback Devices
Card 0, ID `PCH', name `HDA Intel PCH'
? Device hw:0,0 ID `ALC3234 Analog', name `ALC3234 Analog', 1
subdevices (1 available)
??? 2 channels,? sampling rate 44100..48000 Hz
? Device hw:0,3 ID `HDMI 0', name `HDMI 0', 1 subdevices (1
available)
??? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,7 ID `HDMI 1', name `HDMI 1', 1 subdevices (1
available)
??? 2..8 channels, sampling rate 32000..192000 Hz
? Device hw:0,8 ID `HDMI 2', name `HDMI 2', 1 subdevices (1
available)
??? 2..8 channels, sampling rate 32000..192000 Hz
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device plug:ardopout Rate 12000
WARNING: Inconsistent ALSA playback configuration: 21333 * 12000
!= 256 * 1000000.
This will result in a playblack sample rate of 12000.187503
instead of 12000.
This is an error of about -15.625244ppm.? Per the Ardop spec
+/-100ppm should work well and +/-1000 ppm should work with some
performance degredation.
WARNING: The -A option was specified.? So, ALSA misconfiguration
will be accepted and ignored.? This option is primarily intended
for testing/debuging.? However, it may also be useful if ardopcf
will not run without it.? In this case, please report this problem
to the ardop users group at ardop.groups.io or by creating an
issue at .
Opening Capture Device plug:ardopin Rate 12000
cannot set capture sample rate (Invalid argument)
Error in InitSound().? Stopping ardop.
I'm running an older version of Ardopc that does work.
73 Niels PD9Q
Op 2-1-2025 om 23:18 schreef Rich
Sahlender via groups.io:
toggle quoted message
Show quoted text
Hi
John et al,
Although I've had no issues for several years using your ardopc
both x86 and x64 I finally got around to testing with ardopcf for
no good reason other than to busy myself for a few hours given the
claim of many bug fixes... which led me to this thread from back
in July.
I am so far only able to make ardopcf work by dedicating the ALSA
audio device. Everything else I try including completely replacing
the .asoundrc here with dmix, dsnoop, and plug entries as in your
example all fail complaining about something called the playback
"period size". I even tried specifying multiple combinations of
periods, period_time, buffer_time, period_size, and buffer_size in
the .asoundrc to no avail.
So before getting into any details I should mention I have no
inclination to change what works and your ardopc / ardopc64 work
fine here with no problem sharing the audio device via dsnoop and
dmix. I am posting this mostly to ask if you or others in the
group have been able to make ardopcf share the audio device on x86
/ x64 systems (I think the initial thread was for rPi's which I do
not use here) and more importantly if the claim of many bugs being
fixed in ardopcf make it worthwhile to switch from ardopc(64)
assuming it can be made to share audio. Otherwise not experiencing
any "bugs" in ardopc(64) here I may as well just leave things
alone.
There are FWIW some limited details below.
73 de Rich WA3WLH
Here is an example of how I use your ardopc64 and share the audio
without issue using my .asoundrc:
./ardopc64 8515 IC7700_asym IC7700_asym
ardopc Version 1.0.4.1mBPQ-Debug5
-SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device IC7700_asym Rate 12000
Opening Capture Device IC7700_asym Rate 12000
ardopc listening on port 8515
Yet using ardopcf with the same .asoundrc fails:
./ardopcf_amd64_Linux_64 8515 IC7700_asym IC7700_asym
ardopcf Version 1.0.4.1.3 ()
- SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device IC7700_asym Rate 12000
cannot set playback period size (Invalid argument)
Error in InitSound().? Stopping ardop.
And finally here is an example of trying ardopcf using a .asoundrc
the includes only what is in your example and edited to change
from hw card 2 to 1:
./ardopcf_amd64_Linux_64 8515 snoop02 mix02
ardopcf Version 1.0.4.1.3 ()
-SNIP-
Using Both Channels of soundcard for RX
Using Both Channels of soundcard for TX
Opening Playback Device mix02 Rate 12000
cannot set playback period size (Invalid argument)
Error in InitSound().? Stopping ardop.
|
Hi Niels,
Thanks for the feedback. I have spent the better part of the last two days reviewing group threads and anything else I could find that might help. I pretty much get the same results you show below with versions?1.0.4.1.1, 1.0.4.1.2, and 1.0.4.1.3 no matter how I tweak values within dsnoop and dmix.
I even tried compiling with different hard coded values as suggested in one of the threads by Peter LaRue and while I have little experience coding for soundcard audio I think the following results from a test with hard coded values suggests that the inability to utilize dsnoop / dmix within .asoundrc is at least in part still an issue with ardopcf and not entirely an alsa problem as some suggest.
WARNING: Inconsistent ALSA playback configuration: 1000000 * 12000 != 12000 * 1000000.
WARNING: The -A option was specified.? So, ALSA misconfiguration will be ignored.? This option is ONLY intended for testing/debuging.? It IS NOT INTENDED FOR NORMAL USE.
Very curious that ardopcf determines 1000000 * 12000 != 12000 * 1000000 ???
Between that error / bug and what seems like little interest in pursuing the issue based on Peter's comments at the bottom of the discussion at I am inclined to pass on ardopcf at least until it is a little further along in development. Running ARDOP_Win.exe via wine on linux works far better on the x86 and x64 systems here than does ardopcf and it plays nice with dsnoop and dmix as long as the wine registry is updated properly.
73 de Rich WA3WLH
|
With both the latest master and develop branches removing the call to? snd_pcm_hw_params_set_period_size_near fixes the sharing problem for me. This is in ALSASound.c or ALSA.c depending on the version.
I haven't noticed any difference in performance compared with using the original source and not using snoop/mix.
73, John
toggle quoted message
Show quoted text
On 05/01/2025 20:44, Rich Sahlender via groups.io wrote: Hi Niels,
Thanks for the feedback. I have spent the better part of the last two days reviewing group threads and anything else I could find that might help. I pretty much get the same results you show below with versions?1.0.4.1.1, 1.0.4.1.2, and 1.0.4.1.3 no matter how I tweak values within dsnoop and dmix.
I even tried compiling with different hard coded values as suggested in one of the threads by Peter LaRue and while I have little experience coding for soundcard audio I think the following results from a test with hard coded values suggests that the inability to utilize dsnoop / dmix within .asoundrc is at least in part still an issue with ardopcf and not entirely an alsa problem as some suggest.
WARNING: Inconsistent ALSA playback configuration: 1000000 * 12000 != 12000 * 1000000.
WARNING: The -A option was specified.? So, ALSA misconfiguration will be ignored.? This option is ONLY intended for testing/debuging.? It IS NOT INTENDED FOR NORMAL USE.
Very curious that ardopcf determines 1000000 * 12000 != 12000 * 1000000 ???
Between that error / bug and what seems like little interest in pursuing the issue based on Peter's comments at the bottom of the discussion at I am inclined to pass on ardopcf at least until it is a little further along in development. Running ARDOP_Win.exe via wine on linux works far better on the x86 and x64 systems here than does ardopcf and it plays nice with dsnoop and dmix as long as the wine registry is updated properly.
73 de Rich WA3WLH
|
Hi
This works very well for me, I don't notice any performance change
either. Works perfectly with the original source and the snoop/mix.
Thanks.
73 Niels
Op 21-1-2025 om 17:57 schreef John
G8BPQ via groups.io:
toggle quoted message
Show quoted text
With
both the latest master and develop branches removing the call to?
snd_pcm_hw_params_set_period_size_near fixes the sharing problem
for me. This is in ALSASound.c or ALSA.c depending on the version.
I haven't noticed any difference in performance compared with
using the original source and not using snoop/mix.
73, John
On 05/01/2025 20:44, Rich Sahlender via groups.io wrote:
Hi Niels,
Thanks for the feedback. I have spent the better part of the
last two days reviewing group threads and anything else I could
find that might help. I pretty much get the same results you
show below with versions?1.0.4.1.1, 1.0.4.1.2, and 1.0.4.1.3 no
matter how I tweak values within dsnoop and dmix.
I even tried compiling with different hard coded values as
suggested in one of the threads by Peter LaRue and while I have
little experience coding for soundcard audio I think the
following results from a test with hard coded values suggests
that the inability to utilize dsnoop / dmix within .asoundrc is
at least in part still an issue with ardopcf and not entirely an
alsa problem as some suggest.
WARNING: Inconsistent ALSA playback configuration: 1000000 *
12000 != 12000 * 1000000.
WARNING: The -A option was specified.? So, ALSA misconfiguration
will be ignored.? This option is ONLY intended for
testing/debuging.? It IS NOT INTENDED FOR NORMAL USE.
Very curious that ardopcf determines 1000000 * 12000 != 12000 *
1000000 ???
Between that error / bug and what seems like little interest in
pursuing the issue based on Peter's comments at the bottom of
the discussion at I
am inclined to pass on ardopcf at least until it is a little
further along in development. Running ARDOP_Win.exe via wine on
linux works far better on the x86 and x64 systems here than does
ardopcf and it plays nice with dsnoop and dmix as long as the
wine registry is updated properly.
73 de Rich WA3WLH
|
Works well now for me too on both x86 and x64. Thank you John!
73 de Rich WA3WLH
|
For those using or testing ardopcf be aware that the latest 1.0.4.1.3_develop looks to have replaced the code in the linux section with updates that now permit ardopcf to share a single sound device without issue and without John's patch. The previous ALSASound.c has been replaced with ALSA.c and the -A parameter previously required along with John's patch has been removed.
I was able to share a single Signalink with QtSoundmodem 0.0.0.73 configured with fx25 and il2p ports, ardopcf?1.0.4.1.3_develop, and VARA HF 4.8.7 via wine without issue. Only been testing for a few hours but so far so good.
73 de Rich WA3WLH
|
Ok. I'll rework my patch for the lastest development version.
73,
John
toggle quoted message
Show quoted text
On 20/03/2025 23:36, Rich Sahlender via groups.io wrote: For those using or testing ardopcf be aware that the latest 1.0.4.1.3_develop looks to have replaced the code in the linux section with updates that now permit ardopcf to share a single sound device without issue and without John's patch. The previous ALSASound.c has been replaced with ALSA.c and the -A parameter previously required along with John's patch has been removed.
I was able to share a single Signalink with QtSoundmodem 0.0.0.73 configured with fx25 and il2p ports, ardopcf?1.0.4.1.3_develop, and VARA HF 4.8.7 via wine without issue. Only been testing for a few hours but so far so good.
73 de Rich WA3WLH
|
Jeff KP3FT