Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 12 of 12

Thread: distorted audio with teensy3.x as usb audio interface connected to an raspberry pi

  1. #1
    Junior Member
    Join Date
    May 2017
    Posts
    19

    distorted audio with teensy3.x as usb audio interface connected to an raspberry pi

    hi,

    i try to use the teensy audio board and an teensy3.6 as usb audio interface connected to an raspberry pi.
    at least it is possible to process audio, but it periodically start crackle. dependen to my buffersice it need more or less time if crackle will start. i configured my pi with jackd to get an low latency guitar fx - pedal. my jackd call "jackd -P75 -p16 -t2000 -dalsa -dhw:1 -p128 -n3 -r44100 -s".

    firstly i was thinking the problem is on my pi. many hours later now, and several test with commercial usb class compliant sondcards like the alesis io|2, which works perfect without any crackle or xruns down to 128 samples buffer at 3 periods -> around 2.9ms input output latency, i think the problem is caused from the teensy usb_sound mode. maybe it is similar to the mac osx crackle problem. i do not know because i have no mac. connected to my linux pc my teensy based usb sound card works perfect with jackd on -p128 -n3 (128 samples and 3 periods). but this will say nothing. the kernel modules for alsa (snd_usb_audio) are heavy modified to run on arm architecture. so an i386 linux snd_usb_audio module works smooth but an arm usb_snd_audio module produce crackle sound.

    did anybody have similar problems or maybe get an teensy as audio interface working with an raspberry pi?
    i use the new raspbian stretch light image as base for my audio raspberry pi(headless system).

    /g
    wolke

    edit:
    i use teensyduino 1.39 . the audio library i used is the latest head cloned from github repository.
    Last edited by wolke; 11-05-2017 at 01:09 AM.

  2. #2
    Moderator Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    939
    The problem might be that the audio sampling rate of the Teensy can’t physically be exactly 44100Hz since it has to be generated by integer division from the bus clock. Thus, it has a sampling rate of 44117.6471Hz. Try with -r44117 or -r44118 as a parameter

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,720
    If you edit the USB audio code in the core library, you can find some leftover debugging code that prints stuff on Serial1 when buffer overflow and underflow conditions occur. Those would be the first place to start looking, at least on the Teensy side.

  4. #4
    Junior Member
    Join Date
    May 2017
    Posts
    19
    hi,
    thx for your quick reply.
    @Theremingenieur, i try your suggested more or less exact samplerates. no effect. think that jackd with alsa as backend use only the normal selectable rates ... 22050 32000 44100 48k ... and so on. but thanks for your suggestion.

    @Paul, i edit/uncomment in usb_audio.cpp and .h to output buffer overruns and underruns as # and !. because i can not simple debug hardwareserial i use Serial.print on usb serial. whatever the result is:

    Linux Pc with jackd at 44100 and 128 samples buffe with 3 periods:
    i get underruns as long jackd is not started. if i start jackd underruns stop. no problems occur. jackd only produce xrunns, for example if you change buffersize at runtime, some under or overruns happens. this dependents if
    you change from high to low values or in the other direction. think this is normal. the sound is really good on my linux Pc and jackd.

    Linux Arm raspberry pi with jackd at 44100 and 128 samples buffer with 3 periods:
    the same than on Pc. screen on /dev/ttyAVM0 monitors "#" if jack is not started. after startup jack no under or over runs happens. even if the crackle sound starts up no under or over runs happens.

    i create a small video. recordmydesktop is currently broken on my sytem so i use a camera to record my monitor. whatever, firstly i start jackd than i play with buffersize to show that over and underunns happens. than i start jack_simple_client. we can hear a silent sine wave. after a while, i fasten the video ~2 minutes in realtime noise start. screen on left terminal show nothing! . than nose stopp slowly and sine sound is back on top. after a while crackle comes (videotime at ~2minits) back. this will happen periodically from now. i stop the video after 3 minutes. sounds at ~1:50 is my coffe cup .

    the three terminals in video are ssh terminals to my raspberrypi:

    Left = "sreen /dev/ttyACM0 9600" this will display the usb.serial output from teensy.
    upper right = run jackd and his normal info debug output
    lower right = commands i made, (change buffer size and start jack_simple_client)



    ok, mainly i want to show that crackle is massive as you can hear . and as i say, the Pi works fine with other usb soundcards. for example my alesis IO|2. an usb 1 class compliant soundcard.

    i am not a kernel programmer or developer or audio engineer. i do not understand the snd_usb communication. that mean this problem is really to complex for me and i can not fix this. hopefully that some experts can go deeper into this.

    /g
    wolke

  5. #5
    Moderator Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    939
    Sounds like a sampling rate problem, though, generating a kind of beat frequency. Most probably, modifying the Teensy Audio lib to work at exactly 48000sps could help as discussed in this thread: https://forum.pjrc.com/threads/42092...5-Hz)-to-48000

  6. #6
    Junior Member
    Join Date
    May 2017
    Posts
    19
    Quote Originally Posted by Theremingenieur View Post
    Sounds like a sampling rate problem, though, generating a kind of beat frequency. Most probably, modifying the Teensy Audio lib to work at exactly 48000sps could help as discussed in this thread: https://forum.pjrc.com/threads/42092...5-Hz)-to-48000
    ok,
    i tried this - no success. i get it running under 48khz. but this workaround seems all around very incompletely in this state of develop. on my pc jackd only run with many xruns at 48khz. usb_capture input produce crackle all the time... usb playback works with many periodically xrunns. at least there is no resampling, playback at 48khz produce a pitch down. so for music creation this modification is in the moment unusable . as i say i am no sound engineer or programmer and really not sure, but it looks that usb rate is on 48khz while internal sound processing runs with 44117.??, so i think 48khz usb_in and usb_out need a resampling with an interpolation algorithmus. maybe linear is good enough... or there is a way that all sound processing in teensy run with 48kz. maybee i miss something in the 48kz forum thread.
    whatever, thx for this suggestion.

    ok,
    my previous debugging at 44100 hz do not report any underruns or overruns connected to an raspberry pi while jackd is running. but in this test jackd run with -s flag. this flag tell my sound backend alsa to ignore xruns, see part of jackd manual
    -s, --softmode
    Ignore xruns reported by the ALSA driver. This makes JACK less likely to disconnect unresponsive ports when running without
    --realtime.
    and now testing without this "-s" flag give other results. but here i am not able to understand the debug output from teensy. because jackd terminate nearly after a time period which correspond with the time period as, in -s mode, periodically crackle sound was created. but the problem is, that in this case if no jackd is running and connected to an soundcard, teensy usb_audio debugging report #(overrunns) all the time. so i am not able to check if an underrun in teensy produce an xrun on jackd(alsa backend) which terminate the jackd server. currently my feeling tells me that this happens. but i get new questions here.

    1. is it normal, if jackd is not connected to my teensy usb_snd_card that usb_audio from teensy report all the time # overruns?
    2. and if it is normal, how can i notic in teensy usb_audio that a connection to an audio driver is established? so i can debug over or underruns on teensy more precise.

    /g
    wolke

  7. #7
    Moderator Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    939
    I'd really look on the RasPi site. The Teensy sends 44117.somewhat samples per second. That's a invariable fact, at least as long as you don't manage to switch the Teensy audio lib over to 48kHz. Thus, each second there are between 17 and 18 samples which the RasPi will most probably accept via USB because USB allows even higher transfer rates, but which jackd or alsa can't consume. You'd have to look if the overrun happens between USB and jackd or between jackd and alsa.

  8. #8
    Junior Member
    Join Date
    May 2017
    Posts
    19
    ok,
    so at this point i give up because usb communication, usb-audio specification and mechanismen exceed my technical understanding! maybe on the raspberry pi(arm architecture) side there are some sync problems in alsa kernel module for usb audio. but i think at least the teensy3 core library usb_audio need some tweeks in AudioInputUSB::update to calculate the right feedback, beside some ideas for AudioOutputUSB::update and endpoints. if i understand the usb specifications only a little bit , than it must be possible to get it working also with asynchronous sample rate. the endpoints need a correct handling. chapter "4.6 AudioStreaming Endpoint Descriptors" in http://www.usb.org/developers/docs/d...cs/audio10.pdf maybe know all the secrets here .

    @paul,
    imo this is a bug in teensy core library usb_audio. can i create a ticket on github? something like ( usb_audio do not work together with alsa on arch arm). i verify the same results on raspberrypi3 and odroid c1. both are (arm) and both produce the same periodical crackle or distortion if running under linux and alsa.

    test to verify.

    1. install jackd2. headless systems need a version without d-bus.
    2. start jackd with something like jackd -P75 -p16 -t2000 -dalsa -dhw:1 -p128 -n3 -r44100 -s"
    3. start jack_simple_client and wait until crackle sound happens

    /g
    wolke

  9. #9
    Moderator Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    939
    It's not a Teensy bug, but the not exactly fitting sample rate is a technical constraint. Most USB audio input devices (i.e. laptop and desktop computers, digital mixers and amplifiers) can synchronize and handle this slight excess of 17sps without problems, even my cheap Behringer USB mixing desk. It's a pity that jackd is so inflexible and I'd rather raise the issue there.

    Besides of that, you have still the option to rewrite half the audio library to work on 48ksps.

  10. #10
    Junior Member
    Join Date
    May 2017
    Posts
    19
    hi,
    It's not a Teensy bug, but the not exactly fitting sample rate is a technical constraint.
    i do not agree completely .

    usb audio data transfer can handle audio data in "Asynchronous Mode" this allow to handle data from asynchronous clock sources at host and target. this is exactly what happens here. ~44117hz @device vs ~44100hz @host. this pdf describe this simplified. https://www.silabs.com/documents/pub...simplified.pdf . so this rate mismatch is
    presumably no problem if handled correctly by the device firmware. so maybe this is an issue in teensy3 core library usb_audio. i do not understand the code inside. but if i am right there is already a try to handle start-of-frame (SOF) operation there.

    and jackd is only an audio server which use and configure different audio backends(drivers) in this case alsa. and at least for usb_audio, alsa "Advanced Linux Sound Architecture" use this module(driver) http://www.alsa-project.org/main/ind...dule-usb-audio which also can handle Asynchronous data transfer.

    maybe i am wrong but imo this rate mismatch is presumably no problem for usb audio.

    /g
    wolke

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,720
    Is there a simpler way to test this on Raspberry Pi, without all the JACK stuff?

    In other words, imagine I have a small pile of Pi1, Pi2, Pi Zero (but no Pi3) boards here, none with SD cards. And I also have LCD monitor, keyboard, mouse, and some blank SD, and a PC speaker. Also in my pile of gear is a USB protocol analyzer, so if I can get this problem to occur, I can plug that in and use a PC to capture and inspect the actual USB communication.

    But the 2 things I don't have are open workbench space that can be used for more than maybe an hour, and time. Really, I can't pour more than perhaps 1 hour into testing this, and if I can't reproduce the problem quickly, I absolutely MUST give up and put all the gear away to clear the tiny workbench for other stuff. Just getting out the hardware, making space, copying some version of Raspbian to the SD card, and lots of other fiddly setup is going to burn most of that hour.

    However, I do have a modest budget to order other items, like a Pi3, if that would help.

    So with those time and space constraints, please give me the very best steps to quickly reproduce this problem. Remember, if anything goes wrong, or anything takes too much time fiddling (more than about 1 hour total) which almost always seems to be the case when I play with Raspberry Pi, I will put everything away and forever resign this problem to "too difficult to reproduce".

  12. #12
    Junior Member
    Join Date
    May 2017
    Posts
    19
    hi paul,

    awsome thx!!!

    a pi2 is good. i also test it on a pi2 with the same result. crackling audio after a while.

    Is there a simpler way to test this on Raspberry Pi, without all the JACK stuff?
    i do not know. under linux for me jackd is the simplest way to configure alsa and all audio hardware. also jack_simple_client output an nice sine wave for audio debugging.

    OK...
    hopefully you use linux...
    ONE HOUR left

    1. Download raspbian stretch(latest) https://downloads.raspberrypi.org/raspbian_latest (~25ninutes)
    2. under linux open a console and go to download directory and type to unzip
    Code:
    user@pc:~$ unzip 2017-08-16-raspbian-stretch.zip
    and to write the image to sd card type:
    Code:
    user@pc:~$ sudo dd bs=4M if=2017-09-07-raspbian-stretch.img of=/dev/mmcblk0 status=progress conv=fsync
    (~15 minutes) important with dd, double check in file(if=xxx) and outfile(of=/dev/yourSdCard) to prevent data lost!

    3. Install sdcard in raspberry pi2 and connect a hdmi monitor, keys and your mouse and an lan cable to your raspberry pi and power up.
    after boot is complete login as user "pi" with password "raspberry"
    4. open an terminal(console) and type
    Code:
    pi@raspberry:~$ sudo apt-get update
    than to install jackd type
    Code:
    pi@raspberry:~$ sudo apt-get install jackd2
    this install all needed jackd stuff on your raspberry. (~5 minutes)

    now 15 minutes left. (hmm, maybe do teensy setup while you download the raspbian image in step one )
    stack an teensy and an sgtl5000 audio board together configure "audio connections" that maybe the microphone or line_in is connected to usb_input and usb_out is connected to sgtl5000 line out or maybe headphone.
    compile and upload the code with usb option "audio+midi+serial". i do this because i also use midi.

    at least connect an headphone or your speakers to the sgtl5000 audio adapter and connect the teensy it to your raspberri pi2 usb port.

    open a second terminal and configure jackd with alsa and a small buffersize like 128 samples.
    Code:
    pi@raspberry:~$ jackd -P75 -p16 -t2000 -dalsa -dhw:1 -p128 -n3 -r44100 -s
    -P75 setup process priority
    -p16 setup max port connections 16
    -t2000 setup two seconds timeout for clients
    -dalsa setup alsa as audio backend
    now, the alsa options follow
    -dhw:1 setup second audio device (raspberry internal card is hw:0 your teensy as usb audio card is hw:1)
    -p128 setup 128 buffers
    -n3 setup n buffers at 3 periods. 3 is mostly used with usb sound cards
    -r44100 setup rate
    -s setup soft mode. xruns not reported to clients. (currently the problem with teensy usb audio allow only soft-mode. without -s jackd crash after a while.)

    if jack is running go to the other terminal and type
    Code:
    pi@raspberry:~$ jack_simple_client
    now you can hear a sine wave form. simple wait and listen to the nice crackle sound after a while.

    you also can open an third and fourth terminal to do some things. for example you can change buffersize while jackd is running by typing
    Code:
    pi@raspberry:~$ jack_bufsize 256
    this change buffersize to 256.

    apropos usb debugging. under linux you can simple cat all usb bus communication. here is a nice howto. https://wiki.kubuntu.org/Kernel/Debugging/USB

    hopefully you got in one hour. i am 99.9999999% sure that you can hear the crackle distortion sound. dependent to buffersize it take more or less time before crackle starts. of course it is also possible to hear this with other audio players directly connected to alsa. but it need more time to start for example audacity, load an sound file, configure audacity to connect to teensy audio card and configure audacity alsa options. this options are completely hidden. so using jackd and jack_simple_client is really more efficient. also jackd is the common audio server if people do audio-artwork on linux machines. pi included.

    /g
    wolke
    Last edited by wolke; 11-15-2017 at 04:02 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •