Zittriges Audio

Hallo zusammen,

ist mir persönlich garnicht aufgefallen, aber einige User "beschweren" sich. Das Audio soll zittrig klingen. Die Ausgaben von Echolink und Hilfetexten klingt allerdings ganz normal.
Ich vermute, dass die USB-Soundkarte eventuell nicht mehr hinterher kommt. Das läuft hier alles auf 16kBit, 48kBit.

Ich möchte gerne mal die interne Soundkarte für die Ausgabe nutzen. Nur was stelle ich jetzt in der Svxlink.conf beim RX1 ein und wie steuere ich die Pegel?

Danke vorab für Eure Hilfe,

Wilm, DL4OCH

Moin,

ich kenne so etwas, wenn eine echolink Verbindung mit Speex aufgebaut wird.
Dann ist bei mir die CPU am Anschlag und es klingt stotternd.
Also wenn über das Relais gesendet wird somit das eingehende mittels Speex „gepackt“ werden muss.
Ansonsten kann ich zum raspberry nichts sagen, hier nicht im Einsatz.

73 Mathias

Hi all,

besteht das zittrige Audio immer oder nur bei EchoLink-Verbindungen?
Matthias hat recht, es gibt Probleme beim Pi und vor allem bei mehreren Speex-Connect's weil die CPU-Last viel zu hoch wird.
Bitte in diesem Fall den Parameter USE_GSM_ONY=1 setzen. Außerdem überprüfen ob die Compilerflags entsprechend gesetzt sind, damit kann man die Last ganz erheblich senken: http://svxlink.de/?page_id=1893

73's de Adi, DL1HRC

Hallo Adi, Hallo Mathias,

nein, dieses zittrige Audio entsteht bei jeglicher Soundausgabe. Ich habe heute ein Audiofile generiert, welches einen 2 minütigen 1kHz-Ton sendet. Hier kann man wunderbar sehen, dass etwa 1 mal pro Sekunde ein weiterer Takt hinzukommt. Weiterhin ein Impuls mit ca. 100 Hz. Vom Netz kann der Impuls nicht kommen, das Relais ist versuchsweise an die Batterie gekommen.

Ich habe schon die Soundkarte gewechselt, leider ohne Erfolg.

Raspberry Last im Empfangs/Sendebetrieb: 27% mit Echolink und Speex
Raspberry Last im Standby (geschl. Rauschsperre): 10,4%

Irgendso mauschelt sich da was in den Audiostream...

vy73 de Wilm, DL4OCH

So,

das waren jetzt beschwingliche Stunden in diversen Foren, die sich nur mit dem Raspi als Medienserver beschäftigten. Und siehe da, nach dem reboot Nummer x kam die Lösung. Nun spricht auch die Dame ohne Probleme, ein Tonruf, den ich mehr als 5 Sekunden im Parrot aufgezeichnet habe, zittert nicht mehr.

Das Problem ist, dass der Raspi zwar USB 2.0 hat, darüber aber auch noch die LAN-Schnittstelle bedient. Will jetzt noch eine USB-Audio-Karte mit USB 2.0 mitmachen, dann ist Schluss im Bus. Pakete werden gedroppt.

Da für unsere Zwecke USB 1.1 mehr als ausreicht ist eine kleine Zeile in der cmdline.txt die Lösung !

Man gehe wie folgt vor:

sudo nano /boot/cmdline.txt

und gebe die folgende Zeile ein:

dwc_otg.speed=1

Damit wird der USB-Port auf USB 1.1 gezwungen. sudo reboot nicht vergessen.

Hier war das anscheinend die Abhilfe. Wer sucht, wird "kluch"

Ich hoffe, dem einen, oder anderen damit geholfen zu haben.

vy73 de Wilm,
DL4OCH, Sysop für DB0EIG

Hi Wilm,

Vielen Dank, ich denke das ist eine sehr wichtige Information für alle Raspberry Pi außer

Vy 73s de Adi

Ich denke soetwas sollte mit unter Tip's und Tricks aufgenommen werden auf der SVXlink.de Homepage.

73
SA7BNT

Tim

Hab'sch gemacht

73's de Adi, DL1HRC

Hallo zusammen,

ich fühle mich geehrt

vy73,
Wilm, DL4OCH

nach meiner Beobachtung treten solche Effekte vornehmlich bei Rechnern mit schwacher Rechenleistung auf.
Da sind die vorgenannten Tipps schon recht gut. Manchmal reicht das aber auch nicht.

Dann lohnt es, die Prioritäten der Prozesse anzupassen, so dass der svxlink-prozess eine bessere Priorität erhält. Wird SVXlink über das script in /etc/init.d/svxlink gestartet, so hat der Prozess eine voreingestellte Priorität von +20. (sichtbar zu machen mit:

top

das ergibt dann in der zeile für den svxlink-prozess

30737 svxlink   20   0 44928 9836 4292 S   5,3  2,0  24:26.69 svxlink

(prozessnr 30737, user svxlink prio 20, nice 0 und danach weitere Informationen)
oder per

ps -u svxlink -o user,pid,priority,nice,command

erzeugt dann z.B.

USER       PID PRI  NI COMMANDsvxlink  30737  20   0 /usr/bin/svxlink --daemon --runasuser=svxlink --pidfile=/var/run/svxlink.pid --logfile=/var/log/svxlink.log --config=/etc/svxlink/svxlink.conf

hier ist in der Reihenfolge der User (svxlink), die ProzessID(30737), die Priorität (20) und der Nicelevel (0), und das vollständige Kommando (/usr/bin/svxlink --daemon ....) angegeben.

in der Datei /etc/init.d/svxlink lässt sich die verbesserte Priorität mittels des Kommandos renice einstellen oder bereits beim Start des Programms einstellen z.B. mit

IOSHED="real-time:1"NICEPRIO="-10"# weiter unten dann in start)...                start-stop-daemon --start --quiet --pidfile $PIDFILE \                --iosched $IOSHED --nicelevel $NICEPRIO --startas $DAEMON -- $POPTS ...

Dann entsteht

USER       PID PRI  NI COMMAND
svxlink  30737  10 -10 /usr/bin/svxlink --daemon --runasuser=svxlink --pidfile=......

Nach meinen Beobachtungen reicht das zumeist aus (Vorsicht: wer es da zu gut meint und die Niceprio deutlich weiter absenkt, kann das gesamte System blockieren!!!)

Danke für Deine Ausführungen !

Das hilft bestimmt vielen, die SvxLink auf noch anderen Platformen installieren wollen.
Bei einem Raspi reicht meine kleine Modifikation allerdings aus. Das Relais läuft ohne Probleme seit Wochen.

Ich werde Deine Vorschläge mal auf einem Testrechner ausprobieren. Wenn es etwas bringt, dann stricke ich das in unser Relais ein.

vy73 de Wilm,
DL4OCH

Hallo zusammen,

da ja heute eine neue Version von Svxlink rausgekommen ist, habe ich mich mal auch an das "nicen" gemacht. Aber irgendwie schaffe ich es nicht, mein Logfile wieder erzeugen zu lassen.

In der rc.local steht jetzt für den Start von Svxlink:

start-stop-daemon --start \
                      --background \
                      --make-pidfile \
                      --pidfile /var/run/svxlink.pid \
                      --chuid root \
                      --nicelevel 10 \
                      --exec /usr/bin/svxlink

Nur, wenn ich hinter die letzte Zeile mein --logfile=/var/www/svxlink.txt setzen will, dann geht das nicht mehr.
Kann mir einer da Hilfe leisten? Ich bin wirklich nicht so Linux-affin.

Danke vorab und einen schönen 1. Rest-Advent,

Wilm, DL4OCH

Lies mal zu man start-stop-daemon nach. Da findest Du Hinweise auf:

• hinter start-stop-daemon muss zunächst einmal alle Parameter für dieses Kommando
• dann muss "--" gesetzt werden (ohne die Anführungszeichen)
• dann folgen die Parameter für den gestarteten Daemon -- also Deine Anweisungen pidfile, logfile usw,

Hilft das weiter?

vy 73
Michael

Hallo Michael,

das mag jetzt am Debian-Wheezy liegen, aber die Funktion klappt irgendwie nicht richtig (bei mir).

Ich habe mir also etwas anderes einfallen lassen müssen, da ich SvxLink direkt aus der /etc/rc.local starte.
Dort steht jetzt folgendes:

printf  "starte SVXLink\n"


svxlink --daemon --runasuser=root --pidfile=/var/run/svxlink.pid --logfile=/var/www/svxlink.txt --config=/etc/svxlink/svxlink.conf


printf "Renice Svxlink um 10"
PID=$(cat /var/run/svxlink.pid)
renice  -n 10 -p $PID




echo "SvxLink gestartet\n"

Ist vielleicht nicht so schön, funktioniert aber auch. Ist ein Mischmasch aus Deinem Code und dem Befehl renice.

Liebe Grüße es vy 73 de Wilm,
DL4OCH

hallo Wilm,

ja, ich weiss: alle betreiben es irgendwie aus rc.local, weil xxx.... nicht geht -- manchmal wider besseres Wissen.

Auch wenn das nun zum Thema "zittriges Audio" etwas themenfremd ist, sei mir trotzdem ein kleiner Hinweis gestattet:

ich betreibe auch ein debian wheezy und bei mir geht es fehlerlos -- allerdings sind die Skripte im svxlink-Verzeichnis "distributions" möglicherweise nicht hinreichend für wheezy geeignet -- für debian squeeze übrigends auch nicht.

Es lag bei mir am Dateikopf und an den Rechten zum Aufrufen der seriellen Schnittstelle und von audio-Devices:
Also bei mir (und anderen) läuft das folgende script /etc/init.d/svxlink zuverlässig

#!/bin/sh### BEGIN INIT INFO# Provides:        svxlink# Required-Start:  $network $local_fs $syslog $ntp# Required-Stop:   # Default-Start:   2 3 4 5# Default-Stop:    0 1 6# Short-Description: Start SvxLink Server daemon### END INIT INFO# Use the following command to activate the start script#   update-rc.d svxlink start 30 2 3 4 5 . stop 70 0 1 6 .# If RUNASUSER !=root then pay attention to the rights of /var/run -- this user should be able to write in this directory # normaly ohnly root can write in /var/run; so my idea is to change the directory where to write the pidfile# change in /etc/default/svxlink the line: # PIDFILE=/var/spool/svxlink/svxlink.pid# here the user svxlink has the needed rights to write to the directory   PATH=/sbin:/bin:/usr/sbin:/usr/bin. /lib/lsb/init-functionsPNAME=svxlinkNAME="SvxLink Server"DAEMON=/usr/bin/$PNAMEtest -x $DAEMON || exit 5if [ -r /etc/default/$PNAME ]; then        . /etc/default/$PNAMEfiPOPTS="--daemon  ${PIDFILE:+--pidfile=$PIDFILE} ${LOGFILE:+--logfile=$LOGFILE} ${CFGFILE:+--config=$CFGFILE}"# runasuser not for the program but for start-stop-deamonUSERRUN="${RUNASUSER:+--chuid $RUNASUSER:$RUNASUSER}"create_logfile(){        touch $LOGFILE        if [ -n "$RUNASUSER" ]; then                chown $RUNASUSER.$RUNASUSER $LOGFILE        fi}case $1 in        start)                log_daemon_msg "Starting $NAME: $PNAME"                create_logfile                export $ENV                start-stop-daemon --start $USERRUN --pidfile $PIDFILE --startas $DAEMON -- $POPTS                log_end_msg $?                ;;        stop)                log_daemon_msg "Stopping $NAME: $PNAME"                start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE                log_end_msg $?                rm -f $PIDFILE                ;;        restart|force-reload)                $0 stop && sleep 2 && $0 start                ;;        try-restart)                if $0 status >/dev/null; then                        $0 restart                else                        exit 0                fi                ;;        reload)                exit 3        status)                pidofproc -p $PIDFILE $DAEMON >/dev/null                status=$?                if [ $status -eq 0 ]; then                        log_success_msg "$NAME is running."                else                        log_failure_msg "$NAME is not running."                fi                exit $status                ;;        *)                echo "Usage: $0 {start|stop|restart|try-restart|force-reload|status}"                exit 2                ;;esac

Ferner die Rechte setzen für den user svxlink als root mit

adduser svxlink audioadduser svxlink dialout

und das dann mit

update-rc.d svxlink start 30 2 3 4 5 . stop 70 0 1 6 .

(siehe oben) gestartet.

Dieses Startskript kannst Du dann entsprechend der vorher erwähnten Ergänzungen erweitern und dann ergibt sich damit der sauber kontrollierte Start auf den Debian-Distrisbutionen.

vy 73
Michael (last edit und korrigiert am 7.12. 15:15)

Hallo Michael,

vielen Dank für Deine ausführliche Hilfe.
Sobald ich wieder eines Raspberry "frei" habe, probiere ich das aus. Zur Zeit fechte ich (erfolgreich) mit dem Noisegate. Funktioniert einwandfrei.
Der neue Link soll am kommenden Mittwoch installiert werden. Aus dem alten Link habe ich dann wieder einen Raspberry zur freien Verfügung.

Liebe Grüße, einen schönen 2. Advent es vy73 de

Wilm, DL4OCH

Wenn es auch lange gedauert hat,

es gibt endlich eine Lösung für das Problem:

sudo apt-get updatesudo apt-get upgradesudo rpi-update

Nach diesen Schritten können wir endlich in der Cmdline.txt den Eintrag

dwc_otg.speed=1

löschen.

Positiver Nebeneffekt ist, dass das nicht reproduzierbare Aufhängen nach dem 2. Durchgang nicht mehr auftritt. Mit dieser Änderung laufen DB0EIG und DB0OHA auf kleinen Raspberries seit mehr als 30 Tagen ohne Probleme.

vy 73 de Wilm,
DL4OCH