cannot open DMIX / DSNOOPed audio PCM's

[TAj-src]

using ALSA .asoundrc file to create a dmix & dsnoop (to share the audio card) ardoppcf cannot open them with the following error:

Opening Playback Device ARDOP0OUT Rate 12000
cannot set playback period size (Invalid argument)

.arsoundrc is as follows

pcm.dsnooped0 {
     type dsnoop
     ipc_key 50000
     ipc_key_add_uid false # let multiple users share
     ipc_perm 0666 # IPC permissions for multi-user sharing (octal, default 0600)
     slave {
           pcm "hw:1,0"
           channels 2
           }
}

pcm.dmix0 {
     type dmix
     ipc_key 60000
     ipc_key_add_uid false # let multiple users share
     ipc_perm 0666 # IPC permissions for multi-user sharing (octal, default 0600)
     slave {
           pcm "hw:1,0"
           rate 48000
     }
}

pcm.ARDOP0IN {type rate slave {pcm "plug:dsnooped0" rate 48000}}
pcm.ARDOP0OUT {type rate slave {pcm "plug:dmix0" rate 48000}}

G8BPQ's ardop works with this configuration.

[pflarue]

@TAj-src,

Thank you for reporting this issue. I have no experience using dmix or dsnoop, so this will require some investigation. I'll add it to my to-do list.

It is possible that the period size settings that ardopcf makes to ensure accurate symbol timing must be coordinated with other software sharing the audio device, but that is just a guess at this point. G8BPQ's ardop does not set this parameter, and thus with some hardware configurations it transmits with inaccurate symbol timing making all but the slowest and most robust frame types unreadable.

[TAj-src]

hi, Thanks for you reply. If your fork is from github it maybe very out of date compared with the binaries that are released by GM8BPQ. You may wish to look at the way the latest sources open the sound card as these may have clues on how this works with DMIX/DSNOOP. They are located at git clone git://vps1.g8bpq.net/QtSM

I run other software on the same audio DMIX but not 100% on what they may do, if different to rates etc.

[pflarue]

I found the following: https://github.com/alsa-project/alsa-lib/issues/109

This indicates that with the proper settings two programs sharing the same hardware may use different period sizes with the proper DMIX settings. It is unclear from that link, but it sounds like it may also matter which program is started first.

ardopcf requires a rate of 12000 Hz and currently uses a period size of 1200 samples, and a period time of 1000000 micro-seconds.

[TAj-src]

Thanks for the information. I have also looking into this and talked to GM8BPQ. He has patched your fork but it is only to remove the requirement you have , which kind of defeats the point.

There are settings as this link says for adding the periods. I have done this but do not know how to test ? I am trying these settings (with -A on the cmd line to stop the error - it returns 256 not 120 :( )

slave { pcm "hw:1,0" channels 1 period_size 1200 periods 1 period_time 1000000 }

[TAj-src]

The weird thing that I still do not understand is the PCM that is defined (as per instructions) is at 48000

pcm.ARDOP0IN {type rate slave {pcm "plug:dsnooped0" rate 48000}}
pcm.ARDOP0OUT {type rate slave {pcm "plug:dmix0" rate 48000}}

Adding the above setting to these type rate sections errors.

[pflarue]

@TAj-src,

Which instructions are you referring to?

[TAj-src]

https://www.cantab.net/users/john.wiseman/Documents/ARDOPC.html#:~:text=Sampling%20Rate%20Conversion

[pflarue]

Thanks. I should have guessed that.

[pflarue]

There has been some recent discussion that relates to this Issue at https://ardop.groups.io/g/users/topic/direwolf_and_ardocf_both/108567735.

As suggested there, the ability to adjust setPeriodSize in OpenSoundPlayback() in ALSASound.c at runtime (and possibly change its default value) might help ardopcf to work with other programs using the .asoundrc file ( https://www.cantab.net/users/john.wiseman/Downloads/alsa-shared-ardopcf-QtSM.txt) provided by and linked to in that discussion by John Wiseman.

Since I don't use other programs that try to share the sound hardware with ardopcf, I asked that those who want this capability should try compiling ardopcf from source using different values of setPeriodSize to see whether this fixes the problem. It was also suggested in that discussion that the order in which the programs wanting to share the soundcard are started may make a difference.