While I have had success using PortAudio to have audio play on the client, I have had issues with the microphone input.
In reviewing the 1.1 docs for this, the screen displays do not show what we see in the program, and consequently it is unclear what the settings really should be.
I have tried MIC, USB and ACC to no avail, and have a clearly defined microphone for which there are only 2 choices of selection from the system (it is the default too). Audio does not go through unless perhaps it is set to MIC, but I’m in another room and that doesn’t work. The reason I say MIC is because I do see noise, but nothing that matches a voice – probably background noise from my servers. The mic from the remote computer does not get through.
Would it be possible to clarify the documentation so it aligns with v1.5 software (and onward)? I am baffled as to whether it must be set to USB, ACC, and the mix between the microphone and data. As well, perhaps there is a way to explain the best approach for a user to be able to determine correct settings. Seems obvious, but every computer and setup differs, so we way for working through it would be most helpful.
Documentation with us always comes last! We are a very small team all with full-time jobs, and updating the manual is always the last job to be done as we would rather be programming.
I know that Elliott has spent a significant time already updating the manual and I think the server page is the last one to do?
The modulation input must ALWAYS follow the physical connection to the rig, so if the rig is connected to the wfview server via USB, then you must select USB in the radio settings tab if you want it to pass audio from the client. This has always been the case as all that control does is tell the rig where to find the audio.
On the server, only select the audio device in the server tab (the ones on the radio access tab aren’t used for anything at the moment when running a server). On the client, only use the audio selections in the radio access tab.
If you are on Windows, you might want to grab the latest weekly automated build from https://wfview.org/download/ this contains a fix that didn’t make it into 1.50 which should sort a lot of audio device selection issues people have been having. Always check the log to make sure that the devices are being correctly opened as well.
Hi - I downloaded and printed the documentation and after reviewing it, I hate to say I am still very confused. All the examples are for Linux systems, and it gets really hard to translate into the WIndows 10 world when the options seem to be far more expansive.
To illustrate, I have attached both client and server snapshots showing all the choices, of which the right combo is elusive. I’ve even wondered if I have to use loopback, but I suspect not.
It would be really nice to see documentation illustrating lots of choices, and HOW to determine which ones are the best candidates to use for both server and client. I’m in hope-n-guess mode right now, and I’m batting 000.
I tried all options on QT-Audio and got no where, but when I tried PortAudio, at least I got audio to the client computer, but not back from it. The only thing I have not done is disabled everything under the sun except one of each input/output on each machine to reduce the choices to the barest minimum.
If I’m having trouble, as an experienced computer guy (by training too), then I’d bet a lot of lesser experienced folks might be running into the same issue. Illustrations showing Windows for client/server would be helpful, as well as the “how to figure out which port”.
Right now, I’m just sitting here wondering how to get past this impasse.
To be honest, I think you are over-thinking it, maybe because you are an experienced computer guy? The illustrations for Linux/Windows would be practically identical, the only real difference is the actual device names which are different on EVERY computer.
For the audio settings within the ‘audio server’ tab, the audio devices will ALWAYS be the ones called USB audio codec. You look to have multiple USB audio codec devices though so first I would check ‘which’ is actually your rig. For the client, they will be whatever local audio devices you have on your computer. There are literally millions of possible PC hardware combinations, so it is impossible to provide ‘best candidates’ as the ones for me are not likely to be the ones for you as you will have different hardware. This is also the reason for providing different audio APIs as there is no one-size-fits-all solution. With Windows though, I find that QT Audio is the best (but that may not be the case for you.)
I would also recommend posting logs rather than screenshots as they really don’t help us to diagnose anything and just take up space on my server The log can tell you an enormous amount about what is going on.
If you haven’t already, I would also recommend trying the latest weekly build from https://wfview.org/downloads you will also need to download the qt5xml.dll file and put that in the wfview program directory along with the downloaded .exe. That contains some audio device detection fixes (and better logging) that didn’t make it into 1.50.
Thank you for the extra clue. It HAS to be “USB audio codec” or some variation, I take it.
My server has 3 of those, and probably one of more are from ICOM. Of course, the client, zero. So, I tried the first USB codec, made sure the server said USB/USB and pointed to first one of those USB codecs. Then on the client, to mike and speaker that seem right. It might be working. Audio works on AM broadcast and I can hear USB audio on 20m. On 10m I tested audio out and the meters at the lower bottom showed audio, and the transmit levels were varying, so I’ll take that as a positive outcome.
The true clue here was that it has to be a USB audio codec. That wasn’t apparent to me, as I was trying every variety of physical device available, so maybe stressing this point in the docs might be worthwhile.
The audio is a bit choppy right now on PortAudio, but I can try further with QTaudio and maybe that will make a difference.
Music to my ears! I’m glad you got it! I have updated the documentation to mention that the device is likely to be named “USB Audio CODEC” and that if there are multiple, it may help to disconnect other radios and USB audio devices first.
The log can tell you an enormous amount about what is going on.
Hopefully it says happy words.