Fragen zu dmesg-TRIM und Musicpd

  • Thread starter Thread starter destiny
  • Start date Start date
D

destiny

Guest
Bin jetzt echt x Jahre ohne ernsthaftem Interesse und Notwendigkeit von Installationen & IT ferngeblieben, vergangenen Monat kam dann doch mal wieder das Verlangen nach 'Basteln' auf.

SoC Board gekauft, Erweiterungskarte für 2x Mini-PCIe bestellt, 2 SSD ran, viel Wiki, viel Google, viel Zeit -> UEFI (what?)... ZFS muss nicht sein, ahja fsck macht Probleme, weil meine Uhr auf dem Board fehlt usw... ist/kann man alles fixen.

Aktualisieren, Installieren, Konfigurieren usw. Geil - Danke FreeBSD. Fühlt sich gut an, flüssig, performant. Danach ein wenig Struggle beim NFS konfigurieren, beten bei der Konfiguration der Soundkarte (Amanero USB DAC), aber Out of the Box. Bitperfect, ja - cool . Musicpd konfigurieren, FLAC's der letzten 10 Jahre rüberschieben - läuft. Tolles Gefühl, sauberer Sound, System läuft Headless per SSH, Backupstrategie und Feintuning folgt, vorab aber nun doch 2 Fragen:

Meine dmesg schmeisst folgende Meldung raus, die mich verdutzt (Firmware, Blacklist, Linux, Samsung, Korrupte Daten im RAID, doch nicht Samsung sondern Linuxkernel ..... pffhhh) und auch mit google nicht korrekt einordnen kann:
.....
usbus0: 5.0Gbps Super Speed USB v3.0
ugen0.1: <0x8086> at usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ada0 at ahcich1 bus 0 scbus0 target 0 lun 0
ada0: <Samsung SSD 850 EVO mSATA 1TB EMT41B6Q> ACS-2 ATA SATA 3.x device
ada0: Serial Number S246NWAG401579E
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 953869MB (1953525168 512 byte sectors)
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN> <------- ???
SMP: AP CPU #1 Launched!


und ich bekomme in den log's vom musicpd hunderte solcher Einträge in Bezug auf ffmpeg:
.....
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Oct 15 22:45 : ffmpeg/mp3: Header missing
Oct 15 22:45 : ffmpeg/mp3: decoding for stream 0 failed
Oct 15 22:45 : ffmpeg/mp3: Could not find codec parameters for stream 0 (Audio: mp3, 0 channels, s16p): unspecified frame size
Oct 15 22:44 : ffmpeg/flac: Could not find codec parameters for stream 0 (Audio: flac, 0 channels): unspecified sample format
Consider increasing the value for the 'analyzeduration' and 'probesize' options
...

da habe ich bei meinen eigenen Recherchen das Gefühl, mich stundenlang im Kreis zu drehen.

Wie kann ich das in Ordnung bekommen? die meisten MP3' sind 320kbps fixed und haben bisher keine Probleme verursacht, die FLAC's sind zu 90% 16bit 44.1kHz aber in selteneren Fällen auch hochauflösender. Der DAC schafft das hoch bis zu sinnlosen 3xxkHz bei 32bit ...

Danke für die Mühe
 
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN> <------- ???
Hallo,

nutzt Du nun ZFS oder UFS2? Wenn UFS2, wie hast Du das Dateisystem angelegt?
newfs -U -t ... ?

Vielleicht mag Deine Samsung kein TRIM.

Kennst Du das hier? Das Howto von Warren lohnt sich.

Zu dem anderen kann ich vorerst nichts sagen.

Viele Grüße,
Holger
 
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN> <------- ???
Hier teilt Dir der Kernel mit, dass die Platte als 4k-Blockdevice verwendet wird obwohl sie behaupted ein 512 Byte device zu sein (was gelogen ist). Und dass die Firmware Bugs in Verbindung mit TRIM hat. Das übliche hier ist, dass es irgend ein Limit gibt wie viele Blöcke auf einmal getrimmt werden dürfen das unterhalb von dem liegt was die Platte behauptet zu können. Das ist also nur die "ich fummel um folgende Firmware-Bugs herum" Meldung.

und ich bekomme in den log's vom musicpd hunderte solcher Einträge in Bezug auf ffmpeg:
.....
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Oct 15 22:45 : ffmpeg/mp3: Header missing
Oct 15 22:45 : ffmpeg/mp3: decoding for stream 0 failed
Oct 15 22:45 : ffmpeg/mp3: Could not find codec parameters for stream 0 (Audio: mp3, 0 channels, s16p): unspecified frame size
Oct 15 22:44 : ffmpeg/flac: Could not find codec parameters for stream 0 (Audio: flac, 0 channels): unspecified sample format
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Hier meckert ffmpeg anscheinend darüber, dass es das Audio-Format aus dem stream raten muss, weil irgendwelche Metadaten fehlen. So lange Du audio bekommst, würde ich das ignorieren. Vielleicht das loglevel runterdrehen, damit Dein Log damit nicht zugespammt wird. Sofern das möglich ist.
 
Das ist also nur die "ich fummel um folgende Firmware-Bugs herum" Meldung.

Im Linux Bereich nennt man das schlicht Quirks (=Macken). Im Kernel werden da elendig lange Listen geführt und so gut wie jede bekannte SSD steht da drin. Gerade im Bereich queued TRIM hagelt es nur so von Bugs.
 
Im Linux Bereich nennt man das schlicht Quirks (=Macken). Im Kernel werden da elendig lange Listen geführt und so gut wie jede bekannte SSD steht da drin. Gerade im Bereich queued TRIM hagelt es nur so von Bugs.
Ist unter FreeBSD auch so, die Meldung heißt nicht umsonst: ada0: quirks
 
Hallo,

nutzt Du nun ZFS oder UFS2? Wenn UFS2, wie hast Du das Dateisystem angelegt?
newfs -U -t ... ?

Vielleicht mag Deine Samsung kein TRIM.

Kennst Du das hier? Das Howto von Warren lohnt sich.

Zu dem anderen kann ich vorerst nichts sagen.

Viele Grüße,
Holger

Hab meine Installation einfach vom erstellen USB-Stick Image via. Sysinstall mit UFS (manual) erstellt.
Danke für den Link, ziehe ich mir in Ruhe rein.

Hier teilt Dir der Kernel mit, dass die Platte als 4k-Blockdevice verwendet wird obwohl sie behaupted ein 512 Byte device zu sein (was gelogen ist). Und dass die Firmware Bugs in Verbindung mit TRIM hat. Das übliche hier ist, dass es irgend ein Limit gibt wie viele Blöcke auf einmal getrimmt werden dürfen das unterhalb von dem liegt was die Platte behauptet zu können. Das ist also nur die "ich fummel um folgende Firmware-Bugs herum" Meldung.

Okay, das ist schade. Wohl nicht zu ändern...
Ich hab im Netz eben Artikel zu genau diesen Problemen >TRIM & Firmware Shit<- unter Linux gefunden, da wurden (wenn ich das richtig verstehe) Blacklists für SSD's erzeugt und nun haben einige - meine oder ähnliche Meldungen, obwohl es gar keine Probleme in der Beziehung gibt. Doofes Gefühl, hier ist es eine Samsung 1TB Mini-Sata mit Sys+DB und ich mag nun garnicht die 1TB Standard SATA noch dranhängen :(

Beides sind rel. aktuelle EVO 850 V-NAND Samsung Consumer Produkte, die wohl irgendwo zwischen 30-50% (Bauchgefühl) auf dem Markt vertreten sind... OMG, die Welt bleibt gleich.

Erstmal Danke, zu den Fehlermeldungen in den MPD Log's bin ich gerade da:

http://www.mp3-tech.org/programmer/frame_header.html

Scheint mir irgendwie die Richtung zu sein... und ja, es müllt pervers das Logfile zu :-)
 
Der Quirk bezieht sich ausschließlich auf Queued TRIM, was FreeBSD erst seit 11.0 unterstützt. Der Kernel erkennt aufgrund des Quirks die SSD einfach mit Unterstützung für normales TRIM und nutzt das. Es ist ein wenig langsamer als Queued TRIM, allerdings wirst du im normalen Betrieb keinen Unterschied feststellen und auf einem Desktop mit seinen relativ niedrigen IOPS-Anforderungen sowieso nicht. Also alles halb so schlimm. :)

Das Problem bei Queued TRIM ist, dass Windows es nicht unterstützt. Und damit haben die SSD-Hersteller so gut wie keinen Anreiz, die Funktion in ihrer Firmware auch ordentlich zu testen. Man kann nun natürlich fragen, wieso sie es denn überhaupt implementieren. Aber nunja...
 
Ich hab dem Ganzen mal einen etwas inhaltlicheren Titel gegeben. Hättest du einen besseren Vorschlag sag bitte Bescheid.
 
ffmpeg und mp3?
Also, in meiner Version aus dem Paketen konnte ffmpeg das gar nicht und ich musste es (als inzwischen letztes) aus den Ports bauen und diese Option (wegen Lizenz...) manuell setzen. Ähm, das bezieht sich natürlich auf test.xyz -> ffmpeg -> test.mp3
Eine Fehlermeldung wie die deine habe ich noch nicht bekommen, aber id3tag (aus audio/id3lib) ist ein gutes Tool (easytag grafisch und komfortabler), um diese Header mal durchzusehen. Ich habe da nicht nur Unverträglichen zwischen verschiedenen Versionen gehabt, sondern insbesondere bei UTF-8 irgendwo drin. Audio spielte dann zwar, aber die Header-Info sorgte für Verdruss (und ich weiß nun nicht mehr, ob UTF-8 das Böse war, oder die Lösung).
 
Der Quirk bezieht sich ausschließlich auf Queued TRIM, ...

Danke für die Erläuterung

Ich hab dem Ganzen mal einen etwas inhaltlicheren Titel gegeben. Hättest du einen besseren Vorschlag sag bitte Bescheid.

Bitte um Nachsicht für den leeren Titel und meine Euphorie, alles gut - Danke

@pit234
Danke, an die Extrarunden mit den Zeichen habe ich ja überhaupt nicht mehr gedacht.... Hab bisher versucht aber weitestgehend UTF-8 zu hinterlegen, auch Musicpd und die IDV3v1 stehen hart auf UTF-8 ..
Irgendwie fand ich die Info's dazu in den letzten Stunden nicht so spannend, weshalb ich den musicpd noch einmal OHNE ffmpeg & IPv6 - aber MIT FLAC & MAD Support bauen lassen habe. Der ffmpeg erscheint mir ein wenig wie ein riesiger klebriger und undurchsichtiger "Haufen", wenn's nicht zwingend sein muss - raus.
Log gelöscht, DB gelöscht (ja - hab gleich die ID-Tag Auswertungen in der musicpd.conf angepasst) dafür ist laut "man" kein einfaches Update geeignet, also Keule raus und bisschen warten. Log auf maximale Gesprächigkeit gesetzt = keine komischen Fehler mehr, dafür ein anderes Phänomen.

Oct 16 23:38 : playlist: play 0:"Dead Can Dance - Into The Labyrinth - 1993/Dead Can Dance - Into The Labyrinth - 02 - The Ubiquitous Mr. Lovegrove.mp3"
Oct 16 23:38 : client: [7] command returned 0
Oct 16 23:38 : decoder_thread: probing plugin mad
Oct 16 23:38 : decoder: audio_format=44100:24:2, seekable=true
Oct 16 23:38 : output: opened plugin=oss name="default detected output" audio_format=44100:32:2
Oct 16 23:38 : output: converting from 44100:24:2


Der MPD füllt von 24bit auf 32bit auf? Bei allen 24bit mp3's hier ... kein Drama, aber nicht mein Wunsch.
Hab extra sämtliches Resampler/Mixer/Equalizer/Gain & Normalization Gedön's an die Kette gelegt. Versuche dem mal auf die Spur zu kommen, oder jemand von Euch hat eine Erklärung/Idee?

Oct 16 23:55 : client: [9] process command "sticker get song "Dead Can Dance - Anastasis (24bit 44kHz FLAC) - 2012/Dead Can Dance - Anastasis (24bit 44kHz FLAC) - 06 - Opium.flac" rating"
Oct 16 23:55 : client: [9] command returned 2
Oct 16 23:55 : decoder: audio_format=44100:24:2, seekable=true
Oct 16 23:55 : client: [9] process command "status"
Oct 16 23:55 : output: opened plugin=oss name="default detected output" audio_format=44100:32:2
Oct 16 23:55 : output: converting from 44100:24:2

macht er bei FLAC's im 24bit Format auch :(

Und um noch einmal euphorisch zu werden:

Oct 16 23:57 : playlist: queue song 3:"Dead Can Dance - Dead Can Dance (DFF Remastered) - 1984/04 - Fortune.dff"
Oct 16 23:57 : decoder_thread: probing plugin dsdiff
Oct 16 23:57 : decoder: audio_format=352800:dsd:2, seekable=true

DSD als DFF ohne Gefrickel :)

Achja, funktioniert bei Euch der ncmpcpp aus den Ports (der letzte vom Entwickler/August-2016 Version 0.7.5) ?
 
Der ffmpeg erscheint mir ein wenig wie ein riesiger klebriger und undurchsichtiger "Haufen", wenn's nicht zwingend sein muss - raus.
nur dazu:
Ja, aber was denn anstatt?

Das Problem ist bei mir, dass ich viele Scripte habe, die ich um ffmpeg aufgebaut hatte, weil das mal der alles-Bringer gewesen ist.
Ich kenne ehrlich gesagt auch keine Alternative.
 
Da würde ich gern schlau sein und einen Tip geben können :( . Meine Anforderungen waren:

Dezentraler Musik"server" mit FreeBSD (wegen OSS, UFS2 und weil ich da früher schon einmal Berührung hatte) -> NFS (Samba hat bei mir Performance-technisch im 1:1 mit meinem gefährlichem Halbwissen über 1Gbit/Durchsatz-Vergleich verloren) ist ja einiges hin&her zu schaufeln. Max.15 Watt Verbrauch im Dauerlauf, deswegen 2x Atom/2GB/2TB (wobei die 2. 1TB SSD nur temporär sichern soll und später mal einen externen Link bekommt ...
Knappes TB an Musik in FLAC und MP3 + paar DSD Alben, sauber verwalten und abspielen, Bitperfect - PUNKT. Scheinen MAD und FLAC als MPD Plugin's super zu machen. Leider keine Ahnung, was die Alternative zu ffmpeg ist, wenn man das wirklich braucht.
 
Schau mal hier rein: https://forums.freebsd.org/threads/39019/

Ich würde mein System vermutlich einfach auf 16 Bit und 44 kHz festnageln, wenn es sonst Probleme gibt.

oh, ja - da bin ich schon drüber gestolpert, könnte passen - ist aber an meiner Zielstellung -> Audio XY unangetastet zum DAC schicken <- vorbei und nur Notlösung.

Einen hörbaren Vorteil von höher aufgelöstem Material gibt es ohnehin nicht.

Damit befasse ich mich schon mehrere Jahre, kenne die jeweiligen Meinungen & Website's: HD Audio vs. MP3, DSD vs. PCM, Double-Blindtest, NwAVGuy Texte, Debatten etc...

Ich verstehe die Mathematiker, Physiker , Pragmatiker - aber auch die Spinner, Esoteriker, Goldohren und gnadenlosen Kapitalisten in diesem Geschäft. Goldohren habe ich in den theoretisch hörbaren Frequenzbereichen nach meinen eigenen amateurhaften Test's auch nicht, nur kann ich durchaus den Unterschied einer 320kps MP3 und einer unkomprimierten Datei hören.

Ich weiss wie lächerlich sich das anhört, vielleicht 'Suggestion', vlt. doch technisch erklärbar, denn neben der puren Datei gibts ja noch viele weitere Faktoren (neben der eigenen Kette), die da eingreifen. Meine aktiven Neumann Monitore sind schon eine 'Lupe' und je nach Aufstellung + Raumgegebenheiten, ändert sich da einiges. Letztendlich ist der größte Faktor aber das - was aus dem Studio hinten rauskommt und uns verkauft wird. Das ist leider sehr oft nur maximal mittelmäßig und bestimmt in erster Linie den Höreindruck. Langer Text aber auf den Punkt:
Ich gehöre zu den Menschen, die unter bestimmten Umständen sehr wohl (zumindest denken) einen Klangunterschied ausmachen zu können. Deswegen hämmere ich meine Daten nicht auf 16Bit 44100kHz fest. Würde in diesem Fall ja auch bedeuten, dass ich einen Resampler in die digitale Verarbeitung reinlasse, was ich bisher bewusst nicht getan habe.

Werde kommendes Wochenende mal mit meinem kleinen BSD-Hirn an die Sache gehen. Gestern hab ich den halben Tag verbracht, den Kernel neu zu bauen, natürlich ging's daneben, beim wiederherstellen auch noch den kernel.old in geistiger Umnachtung überschrieben, aber mit der Live-CD (hier Stick) einen GENERIC 11-RELEASE wieder erfolgreich hergestellt, also produktiv betrachtet = Umsonst, aber was gelernt :)[/QUOTE]
 
Letztendlich ist der größte Faktor aber das - was aus dem Studio hinten rauskommt und uns verkauft wird. Das ist leider sehr oft nur maximal mittelmäßig und bestimmt in erster Linie den Höreindruck.

Oh ja, eine gewisse Ausstattung kann da sehr wählerisch machen, das kenne ich. Zum Teil werfe ich mittlerweile gewisse Aufnahmen aus meiner Flac-Sammlung wieder heraus und bemühe mich, sie durch bessere zu ersetzen (und das "besser" beziehe ich hier nicht auf die Musik und die Interpretation, sondern auf die Kompetenzen der jeweils für die Aufnahmen verantwortlichen Tonmeister).

Viele Grüße,
Holger
 
Unabhängig davon ob höher aufgelöstest Audio nun was bringt oder nicht. Wenn sie schon im 24bit Format vorliegen, dann möchte man schon, dass da zwischendurch nicht noch dran rumgerechnet wird. Und darum sollte es hier wohl in erster Linie gehen und nicht um den Sinn und Unsinn von Audiophilie.
 
Na klar: Das sollte mit den Tipps aus dem einen Thread auch passieren. Diese Zeilen in "/etc/sysctl.conf" sollten was bringen (natürlich nur für das entsprechende Device):
Code:
dev.pcm.0.bitperfect=1
dev.pcm.0.play.vchans=0
dev.pcm.0.rec.vchans=0
 
Zum Thema 24 Bit: http://people.xiph.org/~xiphmont/demo/neil-young.html

Zum Rest: Ergebnisse wissenschaftlicher Forschung sind keine Meinungen, sondern sind als Fakten zu betrachten bis man das Gegenteil bewiesen hat.

Hab beim Schreiben meines Postings - gewettet, dass der Link kommt... Würde gern was dazu sagen, aber beim Thema bleiben

Na klar: Das sollte mit den Tipps aus dem einen Thread auch passieren. Diese Zeilen in "/etc/sysctl.conf" sollten was bringen (natürlich nur für das entsprechende Device):
Code:
dev.pcm.0.bitperfect=1
dev.pcm.0.play.vchans=0
dev.pcm.0.rec.vchans=0

Hatte ja schon geschrieben, dass der durchgearbeitet ist, derzeit schaut es so aus:

hw.snd.default_unit=0
hw.snd.maxautovchans=0
dev.pcm.0.play.vchans=0

dev.pcm.0.bitperfect=1

Da meine Karte (reiner DAC) keinen Eingang bietet und die dmesg in Sachen "dev.pcm.0.rec.vchans=0" natürlich gespuckt hat, hab ich den Eintrag entsorgt.

Scheint aber tatsächlich mit der Hardware zusammen zu hängen, werde weiter lesen und versuchen zu verstehen.
 
Back
Top