USB-Mikrofon funktioniert nur mit 48khz

[SingenderGnom]

Hallo,

ich möchte mein USB-Mikrofon, ein AT2020USB+, unter Debian Jessie und Raspbian Jessie zum Aufnehmen nutzen. Allerdings gibt es den komischen Effekt, dass die Aufnahme mit 48khz und 16 Bit wunderbar funktioniert, allerdings Knackser auftreten, sobald ich beispielsweise auf 44.1 kHz aufnehmen möchte. Muss ich das Mikrofon vielleicht dazu zunächst auf die passende Sampling-Frequenz umschalten? In beiden Betriebssystemen wird das Mikro über snd-usb-audio eingebunden (keine Ahnung, ob es da noch andere Module gibt). Mir kommt es so vor, als ob das Mikrofon auf 48 kHz sampelt und die Datenübertragung asyncron wird, wenn dann nur mit 44.1 kHz Daten abgeholt werden.

Danke für eure Hilfestellungen!

[pferdefreund]

Probiers mal mit Jack und lass den mit 44.1 laufen. Der resampled intern wie er es braucht. Klappt bei mir mit allen. Gibt auch - glaube ich ein alsa-plugin für sowas.
Wenn die Hardware nur 48000 kann, muss eh resampled werden. Oder halt mit 48000 aufnehmen und dann umsetzen. So es eine CD werden soll, muss das eh auch gemacht werden.

[smutbert]

Es gibt durchaus Geräte, die zwar nominell 44100 Hz Samplerate unterstützen, aber Hardware und/oder Treiber bekommen es nicht richtig hin. Dass du bei einem USB-Mikrofon auf die richtige Samplefrequenz umschalten musst, ist so gut wie ausgeschlossen, aber bei manchen Soundkarten gibt es etwas ähnliches - da kann man eine Samplerate fix einstellen und wenn dann ein Programm eine anderen anfordert, dann tut die Soundkarte bzw. der Treiber so als ob es damit arbeiten würde, was es aber nicht tut. Das kann sich natürlich nicht ausgehen, daher gibt es dann Barry-White- oder Mickey-Maus-artige Stimmen oder Aussetzer oder ähnliches.

Kommt mir aber hier alles etwas merkwürdig vor, weil die 44100 Hz überall bei den technischen Daten angegeben werden und ich anderswo nichts von Problemen gefunden habe. Womit hast du denn aufgenommen?

Ich würde zumindest testweise das simpelstmögliche Programm verwenden → arecord. Dazu musst du nur zuerst Name oder Nummer des richtigen Aufnahmegeräts kennen. Dabei hilft die Ausgabe von

Code: Alles auswählen

$ arecord -l

[SingenderGnom]

Hi,

ich kann morgen mal zwei Beispielaufnahmen mit arecord machen, einmal mit 44.1 kHz und einmal mit 48. Der Qualitätsunterschied bezüglich der Anzahl von Knacksern ist mE schon recht deutlich zu hören. Allerdings gibt es anscheinend noch ein paar weitere Probleme auf dem Pi:

Nachdem ich den Jack-Server mit

Code: Alles auswählen

jackd -p 128 -P 88 -dalsa -dhw:1,0 -n3 -r48000 -s  -S

gestarted habe, bricht jack-record immer nach einiger Zeit ab:

Code: Alles auswählen

jack-record -n 1 test_jack.wav

liefert Fehlermeldungen der Machart

Code: Alles auswählen

time jack-record -n 1 -p system:capture_1 test_jack.wav
jack-record: overflow error, 4096 > 4095

real	1m30.552s
user	0m0.350s
sys	0m0.890s

Mir ist allerdings aufgefallen, das jack-record etwa im Gegensatz zu arecord anscheinend recht wenig eingesetzt wird. Hat das einen bestimmten Grund?

Jedenfalls ignoriert JACK anscheinend auch locker-flockig mein '-p 128':

Code: Alles auswählen

pi@raspberrypi:~ $ jackd -p 128 -P 88 -dalsa -dhw:1,0 -n3 -r48000 -s  -S
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 88
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:1,0|hw:1,0|1024|3|48000|0|0|nomon|swmeter|soft-mode|16bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 3 periods for playback

Außerdem ist mein /var/log/messages auf dem Pi voll mit:

Code: Alles auswählen

Apr 28 21:52:16 raspberrypi kernel: [30949.031559] Transfer to device 9 endpoint 0x2 frame 1970 failed - FIQ reported NYET. Data may have been lost.

Code: Alles auswählen

lsusb
Bus 001 Device 005: ID 046d:c077 Logitech, Inc. 
Bus 001 Device 004: ID 046a:010d Cherry GmbH 
Bus 001 Device 010: ID 174c:55aa ASMedia Technology Inc. ASMedia 2105 SATA bridge
Bus 001 Device 009: ID 0909:001c Audio-Technica Corp. 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[pferdefreund]

Ich kenne den Pi nicht - aber Jack ist für Realtime vorgesehen. Ist der einfach zu langsam. Verwendet der /tmp auf ner Platte oder im /dev/shm bei dir ? Wenn /dev/shm - eventuell zu wenig RAM? Wie sieht den die Prozessorlast und der RAM bei Betrieb von Jack aus ?
Ich habe mit Jack auf nem uralten IBM R52 Thinkpad keinerlei Probleme und das auch nicht, wenn parallel zum Internetradieo Videos geschaut werden und noch ein Großrechner-MVS unter Hercules rennt. Das Ding hat 1Gb RAM und ne 1.8 Ghz-CPU (Centrino). Alt - aber stabil und gut.

[smutbert]

USB ist ja ein bekannter Flaschenhals beim Raspberry, weil so ziemlich alles an einem Bus hängt, da kann es schon einmal haken. Nicht umsonst gibt es Listen [1], [2] mit problemlos funktionierenden USB-Audiogeräten für den Raspberry, hilft aber bei diesem (oder überhaupt irgendeinem) Mikrofon offensichtlich nicht weiter...

Zumindest die Meldungen (ebenfalls mit USB-Audio) ist hier [3] jemand mit der Kerneloption dwc_otg.fiq_fsm_mask=0xF (in der »cmdline.txt«) losgeworden.

Um welchen RPi und welche Raspbian/Kernel-Version handelt es sich?

[1] https://puredata.info/docs/raspberry-pi
[2] http://elinux.org/RPi_VerifiedPeriphera ... ound_Cards
[3] https://discourse.osmc.tv/t/usb-audio-m ... dmesg/7333

[SingenderGnom]

Hi smutbert & Pferdefreund,

danke für eure Hilfe soweit. Also es ist ja sogar ein Pi 3 mit vier Prozessorkernen und 1GB RAM, der gerade erst in Deutschland auf den Markt gekommen ist, auf dem kann man laut Videos auf Youtube auch ein (emuliertertes) Mario Kart 64 ohne Probleme zocken. Die Prozessorlast ist dementsprechend dauerhaft deutlich unter 10%, wenn ich nur jackd und ein einfaches Aufnahmeprogramm wie jack-record starte. Ich habe den Kernel bereits neu mit low-latency (Kernel-Preempting) Option kompiliert. Ich vermute, dass der FIQ-Fehler mit dem USB-Subsystem zusammenhängt, wie smutbert sagte. Den Switch in der cmdline.txt werde ich mal ausprobieren, und das Mikro außerdem versuchsweise per USB-Hub an den Raspi hängen - angeblich hat das den Fehler auch schon einmal behoben. Wobei ich den Zusammenhang nicht ganz verstehe ...

Dass Jack die Period auf 1024 gesetzt hat, das lag anscheinend einfach an der falschen Reihenfolge der Parameter . Wenn ich -p 128 vor -r 48000 schreibe, dann klappt es. Der Hinweis mit /tmp/ und /dev/shm gefällt mir. Der Pi läuft ja von einer SD-Karte, und deshalb mag es wohl sein, dass diese ab und zu nicht schnell genug für den Buffer ist. Ich war davon ausgegangen, dass jack-record immer das aktuelle Verzeichnis zum Buffern nutzt. Ich glaube aber, dass /tmp momentan noch auf der SD-Karte liegt. Ich werde heute abend mal das /tmp-Verzeichnis ändern und die versprochenen Probeaufnahmen machen, ein paar MB RAM von meinem Gigabyte opfere ich Jack gerne. Die Nutzung einer Ramdisk als /tmp sollte ja problemlos möglich sein, oder? Oder kann man einem Programm sogar einfach per switch oder Umgebungsvariable mitteilen, wo es buffern soll?

Um welchen RPi und welche Raspbian/Kernel-Version handelt es sich?

Es ist der Raspberry Pi 3 Model B.

Code: Alles auswählen

pi@raspberrypi:~ $ uname -r
4.4.8-v7+
pi@raspberrypi:~ $ cat /proc/version 
Linux version 4.4.8-v7+ (pi@raspberrypi) (gcc version 4.9.2 (Raspbian 4.9.2-10) ) #2 SMP Wed Apr 27 21:21:39 UTC 2016
pi@raspberrypi:~ $ cat /etc/issue
Raspbian GNU/Linux 8 \n \l

Der Kernel wurde dabei wie gesagt mit Low-Latency-Desktop-Option (Kernel Preempting und 1kHz-Timer) kompiliert.

[pferdefreund]

soweit mir bekannt ist, nutzt jack von sich aus schon /dev/shm - wenn dann allerdings deri Pi anfängt zu swappen, dann ist es eben kein echtes RAM mehr sondern das Pagedataset auf der Karte - und das bremst. Irgendwo kann man doch dem Kernel sagen, swappe bitte später - eventuell hilft das - habe den Begriff swappiness noch so irgendwo im Ohr. Das mal so einstellen, dass der Kernel möglichst wenig swapped.
Oder zum Testen mal swapoff verwenden und swap abschalten, so es die restlichen Anwendungen vom RAM-Bedarf her erlauben.

[SingenderGnom]

Code: Alles auswählen

swapoff

liefert vielversprechende Resultate ... Ich konnte bereits eine halbe Stunde ohne Unterbrechung ('buffer overflow, x > y') aufnehmen und teste es gerade nochmal für eine Stunde.