Increasing Audio Quality

Is there any chance Audio quality can be increased ? there's a big difference listening to a SDR such as Airspy or SDRplay, I know this is necessary for bandwidth reasons but could a several quality options be implemented rather than say low or high ? then the owner can decide based on their bandwidth available.


  • jksjks
    edited September 2018
    I'm not understanding your terminology. By 'low' and 'high' do you mean the fixed 10/5 kHz passband settings when you use the AM/AMN demod buttons? The passband is continuously variable at all times. You can drag the sloping outer edges of the yellow passband symbol (which is tedious unless you're zoomed in far enough). Or use the 'p' and 'P' keyboard shortcuts to narrow/widen the passband respectively. There is also the '/' and ':' notation that can be used in the frequency entry box to set the passband value precisely. This is not completely documented yet but is the same as what's documented for URL frequency entry:

    If by 'quality' you mean how it sounds then you could try turning off audio compression ('comp' button on audio tab) and see if you hear any difference.

    Or are you talking about bandwidth larger than the current 12 kHz max?
  • I'm talking about Audio compression in general, while having the "comp" option helps a lot with higher frequencies the lower end suffers a lot.

    Higher quality/fidelity.

    Options like 16 Kbps, 32 kbps, 64 Kbps, 32000 sampling rate, 44100 etc.

    A different Audio CODEC ?

    I noticed on the SDRplay and Airsipy that the higher audio quality makes a difference to a copy of a DX station sometimes the difference between legibility and not, I understand completely that having the bandwidth of USB can't compare but it would be great if audio quality could be increased and it would make listening in noisy conditions less fatiguing.

    What do you think ?
  • I think it's a good exercise for the user, lol.
  • Good exercise trying to pick stations out of noise ? lol yeah , not sure about exercise but can be fun, it would be nicer to have better quality audio for Dx'ing and for general AM listening.

    I have my 2nd Kiwi ordered and Linear PSU on the way :-)
  • No, I meant adding the stuff you mentioned (different sampling rates, codecs etc.) Someone else can think about that. I'm tired..
  • Ah go on you can do it, think of all the money you're making muhahahaa :-)
  • i am confident what "o00scorpion00o" wants, is the bandwidth to be increased from 12Khz to 20Khz as this will increase the fidelity of the audio from 6Khz to 10Khz.
    but i do realize that there is alot of changes that must be made to the code in order to make this work plus, this change may push the hardware to its limit but a work-around may be to use only 4RX channels instead of 8RX channels.
    i would gladly sacrifice the additional RX channels to provide high fidelity AM/SSB audio since there are many transmissions that exist (like SWBC stations) where 10Khz audio is being used.
  • Use SSB coherent detect and put the filter around the whole sideband out to 10 kHz then.

    Heck, I can't even hear 4 kHz any longer!

    Glenn n6gn
  • have some fun.... try a command like this,10000lsb You may find you have better fidelity. There appears to be a bug though, as that gave me usb but one sideband or the other is all you need.
  • edited December 2018
    WA2ZKD & n6gn, i have tried that "trick" before, it does not actually work, the audio response is still limited to 6Khz and the bandwidth is still 12Khz - only the "slider" changes.
    i have considered changing parameters within the "kiwi.config" file, specifically this entry:
    // rx // don't forget to redo the CIC filter compensation when SND_RATE changed DEFp SND_RATE 12000 DEFp RX1_DECIM 505 // to get near 12000 for integer WSPR sample rate DEFp RX2_DECIM 11 // 505*11 = 5555, 66.6666M/5555 = 12001.188 Hz
    but i do not know if this change will make the necessary changes for the openwebrx interface to reflect the bandwidth changes and im not comfortable at this time doing a build to find out.
    it would be nice if there was some documentation available.
  • OK. I suspect that unless one can get the carrier frequency and phase correct, truly position the carrier correctly, that perhaps it is no longer "hi fi" anyway.
    I think it's clear that the hardware could be made to do it but this does seem outside the original scope of the project. While one is considering changes such as this, someone else might want wide-band FM if we add VHF-microwave block converters (I'm considering this on my list of projects).
    I'd say "have at it" if you like, but perhaps not a mainstream requirement.
    Just my opinion.
    Glenn n6gn
  • edited December 2018
    considering most of the content received on the Kiwi is AM/SSB and the existence of such HF transmissions exceeding the ITU standard of 9/10Khz modulation bandwidth, i think it would be appropriate to have at least 20Khz IF bandwidth available on the Kiwi.
    10Khz audio fares much better as a minimum than the maximum 6Khz audio Kiwi provides.
    after all, this is the 21st century, not the 20th.
  • have you tried using I/Q and an external decoder?
  • edited December 2018
    WA2ZKD - yes i have - it is limited to 12Khz total bandwidth.
    it seems to be configured for 12Khz at the hardware level (see previous post about kiwi.config).
    simple confirmation from the developer that the hardware can support 20Khz bandwidth would encourage me to do the necessary code modifications but id rather not risk "bricking" or damaging the device as a result of changing the SND_RATE value in kiwi.config from 12Khz to 20Khz especially when code documentation isnt available.
  • You cannot simply change the values of SND_RATE, RX?_DECIM and rebuild the Kiwi server code. Changing those values has implications for the FPGA Verilog which must then be rebuilt. Worse, those values are very carefully tuned to match other hardware limitations (buffer sizes, SPI bandwidth, Beagle realtime requirements, etc.)

    It's out-of-date now but you can read about some of these issues in the design review document:
  • thanks for that information and the design document.
    that is how i assumed it would be, as you stated it.
    the question is, if i proceeded to rebuild under this chosen specification, would reducing the available RX channels to four (or less) be a sufficient trade-off to operate under the top limitation of the FPGA and associated hardware ?
  • jksjks
    edited December 2018
    You may not know the full history. The current SND_RATE 12k was originally developed for the 4snd/4wf configuration (it used to be less: 8.25k). It was only found through trial-and-error that 8snd/2wf was possible. And that required a new FPGA sound buffer geometry and other careful tuning to get working. I originally thought only 6snd/2wf would be possible, which was much less interesting. 8snd/2wf was motivated by trying to get more WSPR decoders running in parallel and greater worldwide channels for TDoA. WSPR ultimately failed because of insufficient Beagle cpu cycles with 8 WSPR decoders running simultaneously. But the situation was saved with Rob's kiwirecorder script using the stock WSPR decoder running on non-Kiwi hardware.

    Getting greater than 12k from 4snd/4wf is a separate problem requiring a different architecture from trying to get the maximum IQ bandwidth possible from a single channel (i.e. making the Kiwi act like all other USB-based SDRs out there that use external PC-based control software).

    The problem with this sort of development is that you are pushing all the soft boundaries to their absolute limit. And because there are so many competing processes for resources (e.g. GPS, extensions) you just don't know what's going to give out first. Are you going to run out of SPI bandwidth to handle the audio without dropouts with all possible loading from the GPS? What about running out of cycles on the little eCPU on the FPGA? There are a dozen considerations like this. So you are reduced to incremental development, testing and measurement (there are some built-in realtime measurement tools to help answer some of these questions). Overall this means the total architecture has a very steep learning curve and you're unlikely to make a major change like this easily.

    Why is the Kiwi like this? Is this poor engineering? No. It's because the Kiwi was designed to sell for $299/$199 yet have its unique feature set that is different from every other SDR out there. This required a huge effort in optimized/compromise engineering.
  • thanks for that insight jks, ill review the document and available documentation.
    if i can rebuild this for better sound quality on AM/SSB and make some trade offs in other areas, ill do it.
    the idea here is to increase the fidelity of the sound, there is a community of hobbyists that would like this for Kiwi.
    if i am successful with this project, id like to share it.
  • Dealing with the Xilinx FPGA tools is an absolute bear. I hope you've had some experience with this. I have written up a few hints. Look at the files:
  • yes sir - i have read them - to make life easier, i use WinSCP to access the files on the Beagle, putty to command it.
  • jksjks
    edited December 2018
    Here's what I do. I have a git clone of the current Kiwi disto on my Mac. I edit there and compile to get the compilation bugs out. The main Makefile detects when you're not compiling on the Kiwi and allows different compile tools/flags to be used that are particular to your development machine.

    Then on the target Kiwi I use NFS to mount the Mac sources read-only onto /root/Beagle_SDR_GPS. So I can just ssh into the Kiwi and build/test there without having to be copying all the source files all the time. unix_env/bashrc (that gets installed as /root/.bashrc on the Kiwi) has some hints about setting up NFS on the Kiwi and your development machine (I don't know about Windows though). Because the mount is read-only if the update process is unintentionally started on the Kiwi it won't reverse-write the sources on the Mac and destroy my work-in-progress (super important obviously).

    The various Makefiles have manual targets for copying the Verilog source files to whatever environment Xilinx Vivado happens to be running. In my case I run it on Ubuntu on a VirtualBox VM on my Mac. It works surprisingly well despite all the emulation layers (about 10 minutes to build the FPGA image on a three-year-old MacBook Pro).
  • edited December 2018
    10 minutes :o
    thanks for the advice and info jks, it is really helpful and insightful.
    the more documentation and information, the better.
    i have moderate to good experience with embedded devices using busybox/linux (iot's) but the Kiwi is a bit different from that aspect as well as the custom code thats written for the "project", so i need to ingest and digest as much info thats available about it aside from observing the code that is written in the project directory.
    for now, i feel "safer" customizing and rebuilding the "web" directory to my liking.
  • jksjks
    edited December 2018
    10 minutes is nothing. On my original laptop the project was first developed with it took 40 minutes to build the full FPGA image (all SDR and GPS channels present). That's why kiwi.config has so many options to limit the FPGA configuration and coordinate that info with the C code.

    Be sure to keep good backups if you're tinkering with Beagle_SDR_GPS/web. One 0200-0600Z update and everything will be wiped out unless you have automatic updates turned off.
  • jksjks
    edited December 2018
    Well, it works. Sort of. Try the Beta test Kiwi in Kansas:

    Remember that you can change the passband width by typing / into the frequency box (e.g. /20000 for 20 kHz). Or using the 'p' and 'P' keys.

    There are some problems as expected. I used a SND_RATE of 20250 so that SND_RATE/54 = 375 so the WSPR will still work (it does). There are some audio underruns of course. But I was able to make two regular connections and a WSPR extension connection and it seemed to work okay. The GPS seemed to run fine.

    I think it sounds not quite right with a bandwidth greater than about 16 kHz. That might be a problem with the re-sampler that runs in Javascript on the browser. Measurement for passband flatness is obviously needed. There seems to be some high-frequency artifacts with the compression turned off which doesn't quite make sense.
  • That sounds great already! Would be nice to have that option also in one of the next updates!
  • edited December 2018
    that is awesome.
    you beat me to it jks.
    i think it sounds perfectly fine at 20Khz bandwidth (10Khz audio), thats the minimum standard for hi-fidelity AM/SSB.
    here is an AM station that utilizes 20Khz bandwidth (10Khz audio).
    i agree with eckrot, if we could get this as an option on the Admin panel if having an increase in bandwidth does affect the FPGA/BRAM/Beagle, perhaps operating at 4 RX is the trade-off to have hi-fi AM/SSB audio.
    there are additional benefits with 20Khz bandwidth - DGPS decoding.
    this program Amalgamated DGPS ( can utilize 20Khz bandwidth much more effectively than 6Khz bandwidth to log more DGPS stations on a Kiwi.
    is it possible you can share the modified source code so i can implement this ?
    thanks jks ! (i knew this would work)
    Kiwi will be one of the few to have hi-fidelity audio (10Khz audio minimum), many other online SDR's dont have this but i am sure a large part of the hobbyist community wants this.
  • jksjks
    edited December 2018
    It's not so simple though. There are lots of problems. If you listen long enough you'll realize how many glitches there are. Not only the usual audio underruns but full data pump update failures because the FPGA audio buffers are overflowing when the Beagle can't meet the buffer servicing requirements (interrupt latency essentially). This is really bad because it has subtle and very annoying effects. Example: it will cause the fax extension image to tear/shift. And it will probably cause WSPR decoding to fail.

    If I release this as a replacement for the 12 kHz bandwidth of 4rx/4wf mode you can imagine the howls of protest. So, as you suggest, it should probably be a third FPGA mode. But more experimentation is needed to see if a less stressful configuration might stop the glitching. Perhaps a 2rx/2wf mode @ 20 kHz that is more designed for private listening by the Kiwi owner rather than multi-channel public access Kiwis (although that would still be available).

    Other things to note: Because the waterfall is deliberately the lowest priority process due to its large resource requirements you'll note that it becomes painfully slow much sooner with two or more connections in 20 kHz mode. Also unknown until I check is how many places the 12 kHz bandwidth number is hardwired into code. I tried not to do this, but it may have snuck into some extension code and maybe even the kiwiclient/kiwirecorder code. This will all have to be fixed.
  • i think some Kiwi owners who desire to have 20Khz BW available for their listeners, would appreciate having this as an "advanced option" within the admin menu even if the trade off would be to release certain heavy-use routines on the FPGA/BRAM in order to provide audio smoothly, a slow FPS on the waterfall wouldnt be a deal-breaker, the idea is to provide a "listener experience" to those users (who connect to the Kiwi) who desire it.
    TDoA and GPS wouldnt really be needed to provide this listening experience though advanced users like myself can calibrate the ADC manually (if needed) and easily (zero-beat to <1Hz on separate audio waveform scope display using I/Q on WWV at 10Mhz).
    perhaps additional display info for Kiwi's listed on SDR.HU that indicate the current type of Kiwi (standard/20Khz) so users can choose/avoid that Kiwi. (the user may not care for 20Khz BW) - something displayed like "Hi-Fi Audio" may work.
    not all Kiwi owners may benefit with 20Khz BW but there are some who are located in better geographical areas who can benefit from this.
    i dont want to make this complicated for you or anyone else; with the current hardware, its not possible to have the "best of both worlds" but to have a choice available is better than none.
    i myself use a certain Kiwi to listen to certain "ambiguous" AM/SSB HF broadcasts that i cannot receive locally and often wish the BW on that Kiwi was at 20Khz.
    thanks JKS for taking this into consideration.
  • I think it is better to combine one or more 12kHz wide IQ streams than to change the FPGA+SPI transfer architecture. I already started to make some tests to find out if this is possible, and especially if it works with AGC turned on.
  • HF WB technology uses 24 KHz of spectrum... Harris and Rockwell both have sold systems that are in use
Sign In or Register to comment.