Rauschen statt Musik bei 24-bit

Nur so nebenbei (es hat meiner Meinung nach ohnehin nichts mit dem Problem zu tun): Auf den üblichen (zumindest fast allen) UEFI-Systemen sollte man auch im Legacy/CSM-Modus booten können. Dabei sorgt das CSM-Modul des UEFI dafür, dass sich das System im wesentlichen wie eines mit altmodischen BIOS verhält.

Zum eigentlichen Problem:

Wie sieht denn die Konfiguration von mpd aus?
Da wäre vor allem der audio_output-Abschnitt interessant und vielleicht der Vergleich mit der Konfiguration von diesem AV-Linux.

Ist auf dem System Pulseaudio installiert oder nicht?

Gibt es irgendwelche Meldungen im Log, nachdem der Fehler aufgetreten ist, vor allem Meldungen vom Kernel oder mpd – wenn es kein allzusehr verbasteltes Debian ist, bekommt man die mit

# journalctl -p7 -u mpd.service # joutnalctl -k

(in den Meldungen bis ganz zum Ende scrollen, mit <Ende>, weil dort vermutlich die interessanten Meldungen sind, wenn es welche gibt und vielleicht auch auf die Uhrzeit vor den Meldungen achten, damit klar ist ob die Meldungen tatsächlich etwas mit dem Fehler zu tun haben können)

Hi smutbert.

Danke für die Antwort.

Legacy/CSM-Modus - ist leider nicht möglich. Ist anscheinend eines der ersten Boards, dass nur noch UEFI verwendet.

Wie sieht denn die Konfiguration von mpd aus? Da wäre vor allem der audio_output-Abschnitt interessant und vielleicht der Vergleich mit der Konfiguration von diesem AV-Linux.

Na ja, der ist exakt gleich
Nur das Nötigste ist aktiviert:
#
audio_output {
type"alsa"
name"Star"
device"hw:1,0"# optional
#mixer_type "hardware" # optional
#mixer_device"default"# optional
#mixer_control"PCM"# optional
#mixer_index"0"# optional

Pulseaudio - ja, aber ebenfalls auch exakt so, wie auf dem funktionierenden System.
Über den "alsamixer" habe ich (vorsichtshalber) alle anderen Ausgänge der int. Soundkarte auf NULL gestellt.
Und da ich über die mpd.conf ja nur alsa nutze, sollte das doch auch keine Rolle spielen, oder??

Aber bevor ich jetzt weitermache muss ich sagen, dass ich vor ca. 2 Std. eine interessante Entdeckung machte, aber leider noch keine Zeit zum Verifizieren hatte - das werde ich nachher versuchen.
Folgendes: alle neueren Kernel ab 4.9 machen die Probleme, 4.4 und 4.6 (anscheinend) nicht.
Habe vorhin in ein neues SalentOS den 4.6.xxrRT AVL-Kernel installiert - damit lief das ohne Probleme ...
Aber wie gesagt - erstmal nachher nochmal in Ruhe checken.

Zum MPD-Log - auf diese Idee bin ich noch gar nicht gekommen, bzw. kenne ich das so nicht.
Da bist Du anscheinend schon eher der Linux-Profi - ich eher der ambitionierte Amateur.
Vielen Dank für diesen Tipp.
Werde ich auf jeden Fall versuchen, falls das Problem nochmal auftritt.

By the way - nutze eigentlich für fast alles Linux - meistens Linux-Mint.
Da habe ich ein ähnlich schräges Problem mit der HDMI-Ausgabe gehabt.
Mit LM 17.x keine Probleme - ab 18.x ständige Ruckler (Hänger) bei Bild und Ton.
Habe mir damals schon den Wolf im Netz gesucht, aber keine Lösung gefunden.
Bin dann wieder zurück auf 17.3 - alles supi damit.
Ist ja zum Glück 'ne LTS-Version.

Ok, dann werde ich nachher nochmal den großen Verifizierer machen, melde mich dann.
Drück mir die Daumen, und danke nochmal

Thomas

Nur das Nötigste ist aktiviert: # audio_output { type"alsa" name"Star" device"hw:1,0"# optional […]

Das vereinfacht die Sache, denn damit ist pulseaudio aus dem Spiel, weil es gar nicht genutzt wird und weil es außerdem zwischen den beiden Systemen keinen Unterschied in der Konfiguration oder beim Audiointerface gibt, bleiben als mögliche Ursache für solche Auffälligkeiten, meiner Meinung nach vor allem Kernel und mpd selbst.

Wenn du jetzt eh schon den Kernel in Verdacht hast, würde ich (zumindest testweise) unter stretch den aktuelleren Kernel aus den Backports installieren, momentan ist im Backports-Zweig von stretch Kernel 4.14.
(Wenn du mehr Hilfe dabei brauchst einfach nachfragen.)


"Latency Offset" klingt mir übrigens nach einer Einstellung von Pulseaudio, aber nachdem du mpd die Audiodaten direkt über Alsa zur „Soundkarte“ schicken lässt, wirkt sich diese Einstellung auch nicht auf die Wiedergabe von mpd aus (und mit dem Problem hätte sie ohnehin nichts zu tun).
Allerdings liefert Pulseaudio einen möglichen Ansatzpunkt, falls das Problem nicht so einfach zu lösen ist: Bei der Wiedergabe über Pulseaudio könnte man die Umschaltereien zwischen unterschiedlichen Formaten (Samplerate, -tiefe und Kanalzahl) verhindern.

und das bringt mich gleich noch auf einen anderen Verdacht:
Kann es sein, dass die Audiodaten sich nicht nur im Sampleformat sondern auch in der Samplerate unterscheiden (da habe ich auch schon merkwürdige Probleme erlebt)?
Bei deiner mpd-Konfiguration bekommt die Audiohardware die Audiodaten in dem Format, in dem sie vorliegen, falls sie sie unterstützt oder vorgibt zu unterstützen (letzteres wäre ein gar nicht so seltenes Problem, nämlich, dass bestimmte Sampleraten, -formate nicht problemlos funktionieren obwohl sie es sollten). Dann würde es helfen bei mpd die Ausgabe auf ein bestimmtes Format festzunageln, um zum Beispiel alle Audiodateien mit 24 Bit (bei kleinerer Sampletiefe eben „ausgepolstert“) wiederzugeben, könntest du den Abschnitt so anpassen (die Kommentare habe ich entfernt, damit es übersichtlicher wird)

audio_output { type "alsa" name "Star" device "hw:1,0" format "*:24:*" }

und nur so nebenbei noch eine Kleinigkeit:
Die Angabe von "hw:1,0" ist nicht immer ideal. Sie steht für den möglichst direkten Zugriff auf die zweite Soundkarte, aber wie die Soundkarten nummeriert werden hängt (mitunter auch) vom Zufall ab. Ich verwende an dieser Stelle also lieber den Namen einer Soundkarte, der sich mit der Ausgabe von

$ aplay -l

ermitteln lässt.

Vielen Dank für die ausführliche Info

Kann es sein, dass die Audiodaten sich nicht nur im Sampleformat sondern auch in der Samplerate unterscheiden

Ja klar
Alles dabei - 48, 96, sogar 176,8 khz ... oder so
Da kenn ich nix und spring mal ganz locker hin und her

Bei deiner mpd-Konfiguration bekommt die Audiohardware die Audiodaten in dem Format, in dem sie vorliegen, falls sie sie unterstützt oder vorgibt zu unterstützen (letzteres wäre ein gar nicht so seltenes Problem, nämlich, dass bestimmte Sampleraten, -formate nicht problemlos funktionieren obwohl sie es sollten)

Der DAC kann max. 32-bit/192khz, und macht das eigentlich auch problemlos mit.
Und mit dem AV-Linux auf meinem Rechner klappt das eigentlich bis jetzt auch prima.

Dann würde es helfen bei mpd die Ausgabe auf ein bestimmtes Format festzunageln, um zum Beispiel alle Audiodateien mit 24 Bit (bei kleinerer Sampletiefe eben „ausgepolstert“) wiederzugeben

Das möchte ich lieber nicht, da wird mir zuviel an den Bit's gebogen ...
Denn genau das liebe ich ja (unter anderem) so an MPD - die Schönheit der Schlichtheit (sofern erwünscht - habe meine mpd.conf auf das wirklich notwendige reduziert - gerade mal 49 Zeilen), Bit-Genauigkeit und ressourcenschonende Nutzung.

Die Angabe von "hw:1,0" ist nicht immer ideal. Sie steht für den möglichst direkten Zugriff auf die zweite Soundkarte, aber wie die Soundkarten nummeriert werden hängt (mitunter auch) vom Zufall ab. Ich verwende an dieser Stelle also lieber den Namen einer Soundkarte, der sich mit der Ausgabe von $aplay -l ermitteln lässt.

Die Angaben habe ich aus aplay -l übernommen, aber das kannst du natürlich nicht wissen - also trotzdem danke auch für diesen Tipp.
Wenn man das nicht kennt, kann die Suche nach den Werten schon übel werden ...
Mir hat das zum Glück auch mal ein Kumpel gezeigt.
Meinst du, man kann das auch komplett auskommentieren (#optional), und nur der Name könnte reichen?
Hab ich noch nie probiert ... trau mich nicht

Achso, bevor ich es vergesse - zum "verifizieren" bin ich noch nicht so richtig gekommen - Zeit war zu knapp.
Vielleicht morgen. Bleibe auf jeden Fall am Ball und halte Dich hier auf dem Laufenden

Gute Nacht

Thomas

Die Angaben habe ich aus aplay -l übernommen, aber das kannst du natürlich nicht wissen - also trotzdem danke auch für diesen Tipp. Wenn man das nicht kennt, kann die Suche nach den Werten schon übel werden ... Mir hat das zum Glück auch mal ein Kumpel gezeigt. Meinst du, man kann das auch komplett auskommentieren (#optional), und nur der Name könnte reichen? Hab ich noch nie probiert ... trau mich nicht

Da antworte ich lieber mit einem Beispiel, damit es keine Mißverständnisse gibt. Bei mir sieht die Ausgabe auf einem PC zum Beispiel (gekürzt) so aus

# aplay -l **** List of PLAYBACK Hardware Devices **** […] card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 1: ALC892 Digital [ALC892 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0

und ich würde statt

device "hw:1,0"

lieber den Namen schreiben (den ich oben fett hervorgehoben habe, damit klar ist woher der kommt)

device "hw:PCH,0"

aber um die eigentliche Frage trotzdem zu beantworten: Ja, man kann das komplett weglassen, aber dann weiß mpd von sich aus natürlich nicht welche Soundkarte verwendet werden soll (selbst wenn es nur eine gibt). Es wird dann entweder versucht die erste Soundkarte ("hw:0,0") zu verwenden oder bei installiertem Pulseaudio entscheidet dessen Konfiguration.

Das möchte ich lieber nicht, da wird mir zuviel an den Bit's gebogen ... Denn genau das liebe ich ja (unter anderem) so an MPD - die Schönheit der Schlichtheit (sofern erwünscht - habe meine mpd.conf auf das wirklich notwendige reduziert - gerade mal 49 Zeilen), Bit-Genauigkeit und ressourcenschonende Nutzung.

Mir gefällt mpd auch sehr gut und so etwas in der Art habe ich mir schon gedacht (auch wenn ich die Bedenken in dieser grundsätzlichen Form nicht unbedingt nachvollziehen kann, aber das macht ja nichts).

Wenn du bei den Audiodateien alle Kombinationen von Samplerate und -format zur Auswahl hast, könntest du jedenfalls einmal ausprobieren ob jeder Formatwechsel, nur ein Sampleratenwechsel oder nur ein Sampleformatwechsel Schwierigkeiten verursacht.

Sonst kannst du meinen Vorschlag (zumindest vorläufig ) auch nur als Test ansehen, um herauszufinden welche Wechsel nun die Schwierigkeiten verursachen. Mein erster Vorschlag würde wie gesagt die Audiosamples nur mit Nullen auspolstern bis eine einheitliche Bitrate von 24 Bit (du kannst natürlich genauso 32 nehmen) erreicht ist.
Auf dieselbe Art könntest du testweise auch auf eine einheitliche Samplerate resampeln:

format "44100:*:*"

Da bin ich wieder.

@smutbert

Vielen Dank für Deine tolle und ausführliche Hilfe

Werde sicherlich noch den einen oder anderen Deiner Tipps anwenden (müssen), weil ich langsam aber sicher verzweifle.
Habe schon viele Rechner gebaut und mit verschiedensten OS konfiguriert, aber so etwas hab ich noch nicht erlebt.
Egal was ich mache - es klappt nicht. Dabei ist es doch "nur" Musikwiedergabe, nix exotisches.
Die Hardware ist ebenfalls Standard, aber nur Markenware, kein No-Name - ASUS Board, Kingston SSD, Corsair RAM.

Im Moment gibt es nur eine Linux-Version die vernünftig bei mir läuft, und ausgerechnet die kann ich nicht booten, wegen UEFI.

Das ist echt schräg ....

grummel, grummel ...

Sorry, wenn ich mich kurz in die Diskussion einmische.
Ich würde sagen, daß der Tip von Smutbert am Anfang ein guter gewesen ist:
Du solltest Dir wirklich mal den MPD-Log ansehen. Der gibt normalerweise ganz gut Aufschluß, wenn etwas nicht funktioniert. Bzw. weißt Du, wenn es dort keine Auffälligkeiten gibt, daß etwas anderes, in Deinem Fall wahrscheinlich Alsa, Probleme macht.

Und nur keine Sorge, das Loggen ist nicht so kompliziert:
Einfach MPD beenden, in der mpd.conf logging Funktion einschalten.
Dann MPD wieder starten, einen passenden Übergang wiedergeben, nach "erfolgreichem" Rauschen MPD wieder beenden und logging Funktion wieder ausschalten.

Dann kannst Du Dir in aller Ruhe ansehen, was MPD während der Wiedergabe so alles gemacht hat, oder eben nicht geschafft hat.
Viel Erfolg!

@contadinus

Sorry, wenn ich mich kurz in die Diskussion einmische.

Aber sehr gern, solange es ein konstruktiver Vorschlag oder Tipp ist - immer her damit.
Und dem ist ja so

Meinst Du mit "logging Funktion einschalten" das Auskommentieren von:

log_file "/var/log/mpd/mpd.log"

oder muss ich noch was anderes machen?
Sagt man dazu eigentlich "auskommentieren", wenn man die Raute davor entfernt? (bei mir ist da keine)
Wollte jetzt nicht den Klugscheisser mimen, sondern wusste nicht wie ich das sonst nennen soll

Musste übrigens feststellen, dass das Problem mit dem "Audacious" Player ebenfalls auftritt - also kein reines MPD Problem.
Dort habe ich unter Audio-Einstellungen bei Bittiefe "Gleitkomma" gewählt.
Schöner Begriff übrigens
Wie man auf sowas kommen kann ...
Werde dort mal auf 24-bit stellen und lauschen ...

Einfache Sache das Loggen:

Du schaust in die mpd.conf. Dort findest Du eine Zeile:

log_level"default"

Wenn Du loggen willst, änderst Du das in:

log_level"verbose"

Wenn Du dann MPD neu gestartet hast (mpd.conf wird neu eingelesen) werden sämtliche Aktivitäten mitgeloggt. Deswegen ist es auch wichtig wieder auszuschalten, sonst hast Du irgendwann die HDD voll.

Ziemlich am Anfang der mpd.conf ist ein Pfad für die Datei log_file angegeben. Dort findest Du die fertige Log-Datei.

Viel Vergnügen!


PS:
Grad bemerkt - der Pfad zum log-file steht in der Zeile, die Du vorher gepostet hast:

log_file "/var/log/mpd/mpd.log"

Solltest Du nicht ver-rauten...

Btw:
Falls es Dir hilft - ich hab hier Lubuntu in der aktuellen Version laufen. Da gibts im Zusammenspiel mit MPD keinerlei Probleme.

Wollte nur mal kurz ein Lebenszeichen von mir geben

@contadinus

Vielen Dank - Lubuntu hatte ich auch schon getestet.
Tolles schlankes System, aber leider das gleiche Problem.

Bin noch voll dabei, und hatte jetzt 'ne total schräge Idee.
Dazu eine kleine (Vor)Geschichte:
Das ich mich überhaupt mit Real-Time-Kernel Systemen beschäftigt habe liegt vor allem an "AP-Linux".
http://www.ap-linux.com/
Da hatte ich mir die aktuelle Version 4 besorgt, und konnte die auf keinem meiner relevanten Rechner booten ...
Das war auch auch schon richtig kaputt
Weiß (zum Glück) nicht, wie oft, bzw. wie viele Stunden ich das versucht habe ...
Installation klappte eigentlich gut, wenn auch immer sehr nervig, weil man jedesmal auf's neue alles per Hand im Terminal eintippen muss:
https://www.ap-linux...nstall-instructions/
Falls da jemand 'nen Tipp hat, wie man das irgendwie über Copy/Paste lösen kann - bitte her damit.
Bin mit meinen Versuchen gescheitert.
Jedenfalls habe ich dann irgendwann aufgegeben, und nach einer Alternative gesucht.
Bin dann auch dank https://distrowatch.com/ recht schnell fündig geworden.
AV-Linux mit speziellem Custom RT-Kernel liess sich problemlos installieren, klang wahnsinnig gut (bitte keine Diskussionen deswegen),
und alles funktionierte einwandfrei. Selbst auf einem alten Mini-Dell Laptop von 2009 mit 32-bit und 32GB SSD läuft das spitzenmässig.
Diesen lieh ich dann meinem Kumpel zum Testen - der war ebenfalls begeistert!
Daraufhin schlug ich ihm vor, einen kleinen, günstigen und leisen HTPC zu bauen,
damit er dann auch dauerhaft mit AV-Linux hören kann. (ich und meine große Klappe)
Na ja, und den Rest der Geschichte kennt ihr ja
Und jetzt nochmal die total schräge Idee - ich versuche mal AP-Linux auf seinem Rechner zu installieren ...
Würde mich nicht wundern, wenn das jetzt einwandfrei klappen sollte
Also ran an die fröhliche Tipperei


Thomas

P.S.: Soviel zum Thema "kurzes Lebenszeichen"

AP-Linux - hat nicht geklappt.
Keine Chance wegen UEFI.
Versuche jetzt nochmal in Linux-Mint 18.3 den 4.4 AV-Linux Kernel zu installieren.
Wenn das auch nicht klappt, dann weiss ich auch nicht mehr.
Wääre ja schon froh, wenn es mit dem normelen LM-Kernel laufen würde, aber selbst das klappt nicht.
Vielleicht dann noch der Versuch mit der festen Samplerate.
Aber dann rechnet ja der arme Rechner permanent die 44Khz, die überwiegend benutzt werden, hoch.
Ist ja auch nicht so dolle.
Andererseit die hohen SR zu 44Khz zu "kastrieren" ist auch nicht so ...
Hab auch schon überlegt statt USB den "optical out" zu nehmen.
Dann musste ich aber feststellen, dass das neue MB gar keinen hat ...
Mein eigener alter PC schon.
Au Backe - das ist ja echt 'ne harte Nuss.

Habe jetzt in "audacious" einfach mal auf "pulseaudio" statt "alsa" gestellt.
Bis jetzt - keine Probleme.
Ist da etwa Licht am Ende des Soundtunnels ...
Hatte bis jetzt immer nur ALSA benutzt, weil mir jemand dazu riet, und ich bis jetzt auch nie Probleme dieser Art hatte.
Werde es heut abend nochmal checken, dann klappt's bestimmt nicht mehr
Aber falls doch, und es klanglich soweit ok ist. kann mir dann jemand bitte sagen, was ich in der mpd.conf
für "pulseaudio" im Output eintragen muss?

Zur letzten Frage schreibe ich später noch etwas, jetzt schicke ich nur den Beitrag ab, den ich davor geschrieben habe:

Zuerst und nur ganz nebenbei

Musste übrigens feststellen, dass das Problem mit dem "Audacious" Player ebenfalls auftritt - also kein reines MPD Problem. Dort habe ich unter Audio-Einstellungen bei Bittiefe "Gleitkomma" gewählt.

Gleitkomma sagt ja eigentlich nichts über die Wortgröße aus, aber damit sind im allgemeinen und besonders, wenn es um Alsa geht, 32 Bit Gleitkomma gemeint (wenn das Signal weiterverarbeitet wird ist Gleitkomma von Vorteil, aber es verursacht auch mehr Rechenaufwand, der aber auf einem PC der letzten Jahrzehnte nicht ins Gewicht fällt, wenn man nichts besonderes vor hat).


zum eigentlichen Thema:

Die Installation von AV- oder AP-Linux wäre bestimmt nicht nicht das große Problem, aber es wäre schon interessant zu wissen um welche Hardware genau es nun geht. Vor allem das Mainboard wäre interessant, sowohl wegen der UEFI-Geschichte (dass es nicht im Legacy-/CSM-/BIOS-Modus booten kann glaube ich ehrlich gesagt erst, wenn ich im Datenblatt, in der Anleitung oder ähnlichem einen Hinweis darauf finde ), aber auch um sicher sein zu können, dass die Hardware nicht zu aktuell für Kernel 4.4 ist – dann wäre das ohnehin hoffnungslos.

Auch die Geschichte mit Copy+Paste wäre kein Problem:
Du brauchst ja nur ein beliebiges Linux, zum Beispiel irgendein einigermaßen aktuelles Live-Linux (egal ob Mint, Ubuntu, Debian,…) zu booten, dort für eine Internetverbindung zu sorgen und kannst dann die Anleitung in einem Terminalfenster abarbeiten während du parallel einen Browser offen hast.
Nur passt die Anleitung halt erstens nicht so gut zu UEFI und zweitens ist copy+paste nicht ganz ungefährlich, besonders bei so etwas – zu schnell erwischt man eine falsche Gerätedatei und überschreibt eine SSD, HDD, einen USB-Stick… den man gar nicht überschreiben wollte.

Das ich mich überhaupt mit Real-Time-Kernel Systemen beschäftigt habe liegt vor allem an "AP-Linux". http://www.ap-linux.com/ Da hatte ich mir die aktuelle Version 4 besorgt, und konnte die auf keinem meiner relevanten Rechner booten ... Das war auch auch schon richtig kaputt

Was meinst du mit richtig kaputt?

Versuche jetzt nochmal in Linux-Mint 18.3 den 4.4 AV-Linux Kernel zu installieren.

Es wäre der Übersichtlichkeit und Fehlersuche zuträglich, wenn es nicht in jedem Beitrag um eine neue Distribution ginge

Aber ein Kernel, der schon einmal problemlos gelaufen ist (wenn ich den Beitrag in dem du von SalentOS erzählt hast, richtig deute), ist definitiv einen Versuch wert.
Sollte das Problem mit diesem Kernel bestehen sind ja mpd und der Kernel als Ursache ausgeschieden, womit dann, wenn mich nicht alles täuscht hauptsächlich die Alsa-Bibliohteken als Ursache blieben (oder irgendwelche Konfigurationsoptionen, an die ich momentan nicht denke) und die beste Option wäre es meiner Meinung nach sich darauf zu konzentrieren mit AV-Linux eine bekannt funktionierende Distribution zu installieren (wenn der Kernel grundsätzlich auf der Hardware startet, bekommen wir das höchstwahrscheinlich schon hin).

glaube ich ehrlich gesagt erst, wenn ich im Datenblatt, in der Anleitung oder ähnlichem einen Hinweis darauf finde

Habe nochmal alles durchgelesen - es hat nur UEFI
Hier der Link dazu:
https://www.asus.com/de/Motherboards/J1800I-C-CSM/
Falls Du doch noch was finden solltest - her damit
Wenn ich das vorher gewusst hätte ...
Aber vermutlich wird es bald nur noch UEFI geben, weil BIOS nicht mehr die aktuelle und zukünftige Hardware unterstützt.
Z.B. kann es nur HD's bis max 4GB Kapazität.

Du brauchst ja nur ein beliebiges Linux, zum Beispiel irgendein einigermaßen aktuelles Live-Linux (egal ob Mint, Ubuntu, Debian,…) zu booten, dort für eine Internetverbindung zu sorgen und kannst dann die Anleitung in einem Terminalfenster abarbeiten während du parallel einen Browser offen hast.

Na das wäre ja einfach
AP-Linux basiert auf "Arch-Linux" und kann nur im Textmodus installiert werden - kein GUI, kein Browser, nix.
Du musst also den erstellten Stick booten, und hast nur die Shell.
Das ist das Problem. Hab schon versucht die Befehle als Textdatei mit drauf zu packen, ein paralleles Terminalfenster zu öffnen und dann mit "ViM" ...
Keine Chance.
Aber wie gesagt, bin kein erfahrener Shell-Profi. Da gibt's bestimmt eine Möglichkeit, aber ich hab es nicht hin bekommen.

Was meinst du mit richtig kaputt?

Sorry, hätte in diesem Zusammenhang statt "kaputt" lieber "bekloppt" oder "extrem schräg" wählen sollen
Kaputt war nur ich, nach dem 10. erfolglosen Installationsversuch

Es wäre der Übersichtlichkeit und Fehlersuche zuträglich, wenn es nicht in jedem Beitrag um eine neue Distribution ginge

Da ich das nun schon fast 2 Wochen lang mache, habe ich natürlich schon einiges probiert.
Wie gesagt, AV-Linux ist ein ISO-Snapshot, und mit "Systemback" erstellt, und wird dann auch damit wieder installiert.
Also praktisch ein Backup - aber leider auf einem 8 Jahre alten BIOS Rechner erstellt.
So steht es jedenfalls im Forum bei
http://www.bandshed.net/
Wie schon beschrieben, habe ich es ja immerhin geschafft es zu installieren.
Aber booten ist unmöglich.
Es gibt noch eine Möglichkeit :
ein eigenes ISO mit einem Top-aktuellem System erstellen und dann hiermit:
http://bandshed.net/forum/index.php?topic=4116.0
zu probieren. Das wäre kein Problem, weil ich es auch auf einem anderen Rechner drauf habe.
Aber wie soll es anders sein - die Server auf denen die Dateien für ein Upgrade liegen, wurden angegriffen.
Es ist also zur Zeit nicht möglich, ein dafür nötiges Upgrade zu machen.
Oder vielleicht klappt es ja jetzt wieder - hab seit 2 Tagen nicht mehr geguckt.
Wenn das MB ein normales BIOS hätte, wäre es 30 Minuten nach dem Zusammenbau auf dem Rechner gewesen.
Aber nochmal zum Pulseaudio - hat das gegenüber ALSA einen Nachteil?
Der "magische" 2. Test steht ja noch aus ...
Werde es gleich nochmal probieren.

Thomas

2. Test mit Pulseaudio - Rauschen.

Bin kurz vor der Kapitulation. Versuche jetzt nochmal besagtes Upgrade für AV-Linux zu machen.
Sonst fällt mir nix mehr ein.

Potiputt (Beitrag #16) schrieb:

[…] Aber nochmal zum Pulseaudio - hat das gegenüber ALSA einen Nachteil? […]

Aus deiner Sicht bestimmt:

Pulseaudio mischt die Audiodaten verschiedener Anwendungen, bietet eine Lautstärkeregelung in Software und noch einige weitere Funktionen, für deren Funktionieren es aber notwendig ist, dass alle Audiodaten in ein einheitliches Format konvertiert werden (bezogen wieder auf Samplerate, Sampleformat und Zahl der Kanäle, wobei sich bei Pulseaudio 2 Sampleraten einstellen lassen zwischen denen Pulseaudio soweit möglich automatisch die passendere wählt – soweit möglich deshalb, weil Pulseaudio nicht mitten in der Audiowiedergabe das Format wechseln kann).

Es läuft also auf ein ähnliches Ergebnis hinaus, wie wenn du ohne Pulseaudio in mpd ein fixes Sampleformat und eventuell eine Samplerate festlegen würdest.

Gerade wenn der Computer headless läuft und ganz besonders wenn er nicht nur mpd sondern gleichzeitig andere Programme mit GUI und/oder Audioausgabe ausführen soll, muss man sich eine Lösung überlegen wie man es macht, dass mpd und andere Anwendungen auf ein- und dieselbe Pulseaudio-Instanz zugreifen können.
(Pulseaudio ist normalerweise kein systemweiter Dienst sondern wird automatisch von jedem Benutzer gestartet, aber Zugriff auf die Audiohardware erhält normalerweise nur der Benutzer, der gerade lokal am Computer angemeldet ist – für einen Dienst wie mpd, der im Hintergrund läuft ist das eine etwas verzwickte Situation)

Potiputt (Beitrag #16) schrieb:

[…] Habe nochmal alles durchgelesen - es hat nur UEFI Hier der Link dazu: https://www.asus.com/de/Motherboards/J1800I-C-CSM/ Falls Du doch noch was finden solltest - her damit Wenn ich das vorher gewusst hätte ... Aber vermutlich wird es bald nur noch UEFI geben, weil BIOS nicht mehr die aktuelle und zukünftige Hardware unterstützt. Z.B. kann es nur HD's bis max 4GB Kapazität. […]

Ich habe nichts (verlässliches) gefunden, aber es ist tatsächlich auffällig, dass es im BIOS keinen Eintrag für Legacy/CSM zu geben scheint.

Das mit den 2 TB Kapazität ist nicht ganz richtig, entscheidend ist hier das neue Partitionsschema gpt, das sich ganz unabhängig von BIOS oder UEFI nutzen und verwenden lässt. Man kann Festplatten in reinen UEFI-Systemen nach wie vor auf die alte DOS/MBR-Art partitionieren, die nicht mehr als 2 TB unterstützt (und natürlich auch im UEFI-Modus booten und verwenden) und genauso kann man auf einem alten BIOS-System eine Festplatte per GPT partitionieren und damit auch booten (es kann allerdings sein, dass Windows keine dieser beiden Varianten erlaubt).

und jetzt noch ein Hauch Besserwisserei (entschuldige bitte)

Potiputt (Beitrag #16) schrieb:

[…] Na das wäre ja einfach AP-Linux basiert auf "Arch-Linux" und kann nur im Textmodus installiert werden - kein GUI, kein Browser, nix. […]

Das habe ich gesehen und ich kenne arch Linux und habe es einmal ohne Probleme zum Ausprobieren aus einem laufenden Debian (jessie war das damals, aber das ist ja fast egal) heraus installiert.

____


Du schreibst mehr und schneller als ich antworten kann: Dass es mit Pulseaudio rauscht kommt für mich überraschend.

Hast du schon den Kernel von AV-Linux unter Mint oder einer anderen Distribution ausprobiert?
(Das Ergebnis wäre auf jeden Fall interessant!)

Sonst würde ich mir einmal AV-Linux herunterladen und ausprobieren. Ich nehme an, ich hätte keine größeren Schwierigkeiten bei der Installation auf einem reinen UEFI-System und wenn ich damit den Mund nicht zu voll genommen habe, würde ich hinterher natürlich wie ich es gemacht habe und sonst sollte doch immer noch ein Debian oder notfalls eine andere debianbasierte Distribution mit dem Kernel von AV-Linux funktionieren (oder habe ich Beitrag #3 falsch verstanden).

Hab gerade wieder eine neue Entdeckung gemacht
Aber gemach - ich versuche mich zu zügeln

Erstmal danke für die Pulseaudio-Info.

BIOS vs. UEFI + 4 TB Kapazität
Habe ich auch nur irgendwann in den letzten Tagen irgendwo im Netz gelesen, auf der Suche nach
Info zum Unterschied BIOS - UEFI. Musste das ja erstmal versuchen zu verstehen, und wollte es
auch nur als Beispiel anführen. Analog zu FAT32, dass keine Dateien größer als 4GB verarbeiten kannn, im Gegensatz zu NTFS.
Normalerweise bin ich sehr vorsichtig mit dem Argumentieren aus dem Halbwissen heraus.
Aber im Moment passiert soviel neues gleichzeitig, da kann das schon mal vorkommen.

Das habe ich gesehen und ich kenne arch Linux und habe es einmal ohne Probleme zum Ausprobieren aus einem laufenden Debian (jessie war das damals, aber das ist ja fast egal) heraus installiert.

Das finde ich aber total interessant - wie macht man das?
Oder besser gefragt - wie komme ich z.B. im XY Live-System an den anderen USB-Stick mit ARCH ran?
Ist das Live-System Hotplugfähig?
Und falls ja, wie kann ich die Datei zum Ausführen der Installation finden und nutzen?
Das ist natürlich genial, und würde mir vieles in Zukunft vereinfachen.
Würde mich echt freuen, wenn du mir das erklären könntest.
Aber natürlich nur wenn es nicht zu aufwändig ist, und du Lust darauf hast.

Du schreibst mehr und schneller als ich antworten kann:

Versuche halt endlich das Problem zu lösen, weil ich meinem Kumpel einen funktionierenden AV-Linux Rechner versprach.
Klar, warum auch nicht. Schliesslich hatte ich solche Probleme bis jetzt noch nie.
Und jetzt hänge ich hier schon seit 2 Wochen an der Kiste ...

Hast du schon den Kernel von AV-Linux unter Mint oder einer anderen Distribution ausprobiert? (Das Ergebnis wäre auf jeden Fall interessant!)

Jep, habe alle möglichen Kombinationen ausprobiert. Klappt auch meistens gut, aber das Problem bleibt bestehen,
ABER - jetzt kommt die allerneueste Neuigkeit
Über den "TOS-Link" Ausgang meines alten Rechners klappt es einwandfrei. Habe es vorhin in wildesten Samplerate-Konstellationen
ca. 30 Minuten probiert, und es rauschte nicht ...
Also muss es irgendwie mit USB zusammenhängen.
Allerdings kommt damit das nächste Problem - der neue Rechner meines Kumpels hat keinen Optical-Out.

So, ich suche mir jetzt ein paar Mäuse zum Melken und gehe dann schlafen

Gute Nacht mal wieder

Thomas

Moin smutbert.

Sonst würde ich mir einmal AV-Linux herunterladen und ausprobieren. Ich nehme an, ich hätte keine größeren Schwierigkeiten bei der Installation auf einem reinen UEFI-System

Aber gern - vielleicht schaffst du es ja.
Also wie schon erwähnt, die Installation habe ich auch hinbekommen, aber booten des inst. Systems nicht.
Falls du es schaffen solltest, und mir dann sagst wie du das gemacht hast, wäre ich - wie soll ich sagen ... HAPPY

Ansonsten mach ich dann erstmal weiter


Thomas

Hab das Image heruntergeladen und nun testweise auf einem alten Notebook installiert. Da verhält es sich nun wie ein normales Debian, also wäre jedes Problem (dh es gab keinerlei Probleme). Zuerst einmal der grobe Überblick über das Vorgehen:

1. Live-System booten
   Am schnellsten geht das ganze natürlich wenn man direkt AV-Linux bootet und dort nach Möglichkeit auch gleich für eine Internetverbindung sorgt, weil die im letzten Schritt notwendig ist.
   
2. Partitionieren und Formatieren
   Ich habe im Terminal die Partitionen mit gdisk angelegt und formatiert (ein grafischen Programm würde den Zweck natürlich genauso erfüllen, aber ich hab ehrlich gesagt gar nicht geschaut ob bei AV-Linux schon eines mit von der Partie ist).
   
   Jedenfalls sind zwei Partitionen unerläßlich, eine kleine vom Typ ef00, die mit fat formatiert wird (das ist die EFI System Partition, 200 MB genügen, aber mehr stört auch nicht) und eine für weitere für Debian/AV-Linux, die man zum Beispiel mit ext4 formatiert.
   
   swap und weitere Partitionen kann man je nach Verwendungszweck des PCs und Vorlieben natürlich auch erstellen.
   
3. Installation ohne Bootloader (grub)
   Als Mountpoint / für die Partition für Debian/AV-Linux wählen, den Haken bei bei formatieren entfernen, die Installation von grub deaktivieren und installieren.
   
4. Nachträgliche Installation von grub(-efi)
   Nun muss man nur noch das frisch installierte System für chroot vorbereiten, dann in das System chrooten, den vorinstallierten grub entfernen und grub-efi-amd64 installieren
   

Ich kann jetzt nur erahnen, dass du beim letzten Schritt etwas detailliertere Hilfe brauchst, bei den Schritten davor, besonders dem zweiten musst du sagen inwieweit du sie ohne Hilfe schaffst.

Wie groß ist denn die verbaute SSD und soll außer der Audiowiedergabe sonst noch etwas mit dem System angestellt werden?

Hi smutbert.

Vielen Dank für deine tolle Hilfe - echt klasse.
Da bin ich ja anscheinend an einen echten Linux-Profi geraten - supi

Aber eine Frage vorweg: hat das "alte" Notebook ein normales BIOS, oder schon UEFI? Das ist natürlich ganz entscheidend.
Auf Rechnern mit normalen BIOS habe ich es auch immer zum Laufen bekommen, mit ganz normalem GRUB.
Sorry das ich so blöd frage, aber ich kann das nicht erkennen, gehe aber bei einem "alten" Rechner von BIOS aus.
Dann macht doch das ganze mit der EFI-Partition keinen Sinn, oder?

Aber jetzt mal wieder "back to the Rauschen" ...
Habe unabhängig von der AV-Linux Installation eine (wahrscheinlich) ganz entscheidende Entdeckung gemacht:
in einer Schublade gammelte meine gute alte Soundblaster Audigy NX (externe USB-Soundkarte, 24-bit) so vor sich hin.
Also habe ich die an den Rechner angeschlossen, alte Kopfhörer dran und, du wirst es schon ahnen, unglaublich aber wahr - alles in Ordnung !!!
Kein rauschen oder sonstwas. Bin sehr schnell von 16- auf 24-bit und zurück, mit sehr schrägen Samplerates gesprungen - nichts!
Es scheint also an meinem eigentlich sehr, sehr guten DAC zu liegen - aber wie soll ich bitte darauf kommen?
Das war im wahrsten Sinne das Letzte an was ich dachte, aber (falls es dabei bleibt) ist dann auch alles klar.
Dann kann ich mir natürlich einen Wolf installieren ...
Das heisst natürlich noch nicht, dass es bei meinem Kumpel auch läuft - der hat auch einen ziemlich guten und neuen DAC.
Aber möglich ist es schon.
Dementsprechend werde ich erstmal zu ihm gehen, und vor Ort testen.
Werde natürlich hier vom Ergebnis berichten.


Thomas

Ja, natürlich ist das ein UEFI-System. War ein recht frühes System mit UEFI (und der Legacy-Modus ist deaktiviert – außerdem weiß ich ja, dass ich grub in der uefi-Variante installiert habe )

Wobei mich ein netter Mensch aus einem anderen Forum, dem dieser Thread hier nicht entgangen ist, darauf hingewiesen hat, dass das Mainboard vielleicht/vermutlich doch im BIOS-Modus booten könnte:
Im BIOS-Setup gibt es unter "Boot" im "Secure Boot Menu" die Auswahl des "OS Type". In der Einstellungen "Other OS" sollte das Mainboard wohl auch im BIOS-Modus booten.

zum Rauschen:
Dass das zumindest etwas mit diesem speziellen DAC zu tun hat, habe ich von Anfang an vermutet. Ein grundsätzliches Problem beim Betrieb mit USB-Soundkarten wäre längst anderen aufgefallen.
Allerdings macht das die Sache nicht unbedingt einfacher, denn der erste Ansatzpunkt wäre dann wohl der Treiber für USB-Soundkarten. Das ist für die überwiegende Mehrheit der USB-Soundkarten und -DACs ein generischer USB-Audiotreiber, der lediglich einige Workardounds für bekannte Fehler und Eigenheiten spezieller Modelle beinhaltet, aber leider löst bei dir ja ein Kernelaustausch alleine das Problem nicht.

Jedenfalls halte ich es mit praktisch jeder anderen Soundkarte (oder DAC, falls Soundkarte nicht hochwertig genug klingt ) nicht nur für möglich, sondern sogar wahrscheinlich, dass Problem nicht auftritt.

Potiputt (Beitrag #19) schrieb:

[…] Das habe ich gesehen und ich kenne arch Linux und habe es einmal ohne Probleme zum Ausprobieren aus einem laufenden Debian (jessie war das damals, aber das ist ja fast egal) heraus installiert. Das finde ich aber total interessant - wie macht man das? Oder besser gefragt - wie komme ich z.B. im XY Live-System an den anderen USB-Stick mit ARCH ran? Ist das Live-System Hotplugfähig? Und falls ja, wie kann ich die Datei zum Ausführen der Installation finden und nutzen? Das ist natürlich genial, und würde mir vieles in Zukunft vereinfachen. Würde mich echt freuen, wenn du mir das erklären könntest. Aber natürlich nur wenn es nicht zu aufwändig ist, und du Lust darauf hast. […]

Den Datenträger von dem Linux läuft darfst du natürlich nicht abstecken, es sei denn es handelt sich um ein System, das genau dafür gedacht ist und alles in den Hauptspeicher lädt (das trifft zum Beispiel auf grml zu, das gerade für solche Aktionen sehr gut geeignet ist), aber zusätzliche USB-Sticks anzustecken ist kein Problem.

Es muss auch nicht unbedingt ein Live-System sein, sondern kann auch ein ganz normal installiertes Linux sein. Eine Anleitung wie man arch von einem beliebigen Linux aus installiert gibt es im arch-Wiki:
https://wiki.archlinux.org/index.php/Install_from_Existing_Linux

Das Vorgehen mit chroot ähnelt auch dem, was ich gemacht habe, um unter AV-Linux einen UEFI-Bootloader zu installieren.

Moin smutbert.

Ja, natürlich ist das ein UEFI-System. War ein recht frühes System mit UEFI (und der Legacy-Modus ist deaktiviert – außerdem weiß ich ja, dass ich grub in der uefi-Variante installiert habe

OK, war aber nicht so ersichtlich.

"Other OS" sollte das Mainboard wohl auch im BIOS-Modus booten.

Danke für den Tipp, aber das habe ich längst deaktiviert, bzw. genau so eingestellt. Auch die "Windows"-Keys sind komplett deaktiviert.
Bootet aber trotzdem keine Datenträger ohne UEFI ...
Habe auch einen tollen Multiboot-Stick (mit YUMI erstellt), auf dem alle wichtigen OS und Werkzeuge (gparted, clonezilla, etc.) drauf sind.
War ganz toll, dass ich den plötzlich nicht mehr nutzen konnte ... grummel
So durfte ich erstmal wieder für jedes OS/Tool einen neuen Stick erstellen - au mann
Die UEFI-Variante für YUMI (Beta) funktioniert leider auch nicht.
Hast du da vielleicht noch einen Tipp, bzw. UEFI fähige Alternative?

Eine Anleitung wie man arch von einem beliebigen Linux aus installiert gibt es im arch-Wiki: https://wiki.archlinux.org/index.php/Install_from_Existing_Linux

Das ist natürlich super - vielen Dank.
Werde ich auf jeden Fall demnächst ausprobieren.

Ansonsten bin ich sehr gespannt, was heut abend bei meinem Kumpel passiert.

Schönen Tag euch allen

Thomas

Also ich verwende als Allzweck- und Notfall-USB-Stick, einen USB-Stick auf den ich ein normales Debian auf eine ganz ähnliche Art installiert habe und zwar so, dass er auf so gut wie allen (U)EFI- und BIOS-Systemen booten kann. Debian bietet für die Installation aus einem laufenden Linux (vorzugs-, aber nicht notwendigerweise ein Debian oder debianbasierendes System) das Tool debootstrap.
Ich habe sogar einen kleinen Wiki-Artikel darüber geschrieben (den ich aber einmal überarbeiten sollte): https://wiki.debianf...B-Stick_installieren

(Die Installation von grub-efi in AV-Linux habe ich auf dieselbe Art wie im Artikel gemacht. So kann man im Grunde auch beliebige weitere Systeme vom Stick booten - ähnlich wie es wohl mit yumi, das ich aber nicht kenne, auch geht.)

Spezielle Distributionen versuche ich im allgemeinen eher zu vermeiden, das einzige, das ich gelegentlich verwende ist grml

Moin.

Eine Anleitung wie man arch von einem beliebigen Linux aus installiert gibt es im arch-Wiki: ]https://wiki.archlin...isting_Linux

Hab gestern nur mal kurz reingeschaut. Da machte es aber erstmal einen sehr komplizierten Eindruck - vorsichtig ausgedrückt
Wahrscheinlch mit entsprechenden Vorkenntnissen easy, aber sonst ...puh
Da tipp ich dann wohl lieber.
Oder täuscht der Eindruck??
YUMI - guck mal rein. Ist sehr einfach in der Bedienung, hinzufügen und löschen von Distro's geht schnell und einfach.
Im Bootmenü kannst du dann zwischen Tools und Distro's wählen - hat immer hervorragend funktioniert, bis dann UEFI kam

War gestern bei meinem Kumpel - alles gut (bis jetzt)
Habe über 2 Wochen an der falschen Stelle gesucht - prima
Hoffe nur das mein DAC nicht defekt ist. Das wäre echt fatal.


Thomas

Ich glaube nicht, dass dein DAC einen Defekt hat. Vermutlich verfügt er nur über eine kleine Eigenart, die sich nur bei bestimmten Konstellationen aus Hard- und/oder Software zeigt. Bei verbreiteten Geräten, bei denen die Chance größer ist, dass es überhaupt einen zweiten Linuxnutzer gibt, dem so etwas auffallen kann, ist die Chance, dass der USB-Audiotreiber von Linux dafür sorgt, dass diese Eigenart gar nie zum Tragen kommt, natürlich größer.
Nur so rein interessehalber, was sagen denn

$ lsusb $ aplay -l

wenn der DAC am PC hängt?


Der abschreckende Eindruck von der arch-Anleitung täuscht tatsächlich ein (kleines ) bisschen, schon alleine weil zwei Varianten beschrieben sind, die man erst einmal durchblicken muss.
Wenn man dann einmal verstanden hat, was man hier eigentlich tut und wieso, dann ist es lehrreich und halb so schlimm. Wenn man es aus einem Linuxsystem heraus installiert, das bereits konfiguriert ist und das einem vertraut ist, dann finde ich fällt es einem nicht schwerer als die normale arch-Installation ohne inoffizielle Hilfsmittel, die im Endeffekt ja ganz ähnlich abläuft und meiner Meinung nach auch nichts für schwache Nerven ist.
Als „Abkürzung“ finde ich dieses Skript ganz nett: https://github.com/tokland/arch-bootstrap (wird auch im Wikiartikel verlinkt)

Moin.

Ich glaube nicht, dass dein DAC einen Defekt hat

Hoffe es ebenfalls. Fakt ist aber, dass er diesen Fehler erst seit ca. 3 Wochen hat. Vorher gab es keine Probleme.
Habe aber bereits Kontakt mit dem Chef der italienischen Manufaktur aufgenommen.
Ist ein sehr netter Mensch, und so hoffe ich, dass er mir vielleicht helfen kann.
Deine Erklärung mit dem USB-Audiotreiber ergibt aber durchaus Sinn.

$ lsusb $ aplay -l

Mach ich gern, aber dazu muss ich erst am Hifi-Rechner die entsprechenden Screenshots machen, etc..
Ist bei mir a bisserl kompliziert ...
Aber nochmal - es lief sehr lange einwandfrei, und ich habe nichts geändert.
Falls ich es schaffe, mache ich das heute noch.

Bis dahin wünsche ich einen schönen Tag

Thomas

@smutbert
Ok, hab's doch gleich gemacht:

$ lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 046d:c52e Logitech, Inc. MK260 Wireless Combo Receiver Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 004: ID 13fe:3e00 Kingston Technology Company Inc. Flash Drive Bus 001 Device 002: ID 04b4:931b Cypress Semiconductor Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 05a4:9881 Ortek Technology, Inc. IR receiver [VRC-1100 Vista MCE Remote Control] Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub ------------------------------------------------------------------------------------------------------------------------------------------ $ aplay -l **** Liste der Hardware-Geräte (PLAYBACK) **** Karte 0: NVidia [HDA NVidia], Gerät 0: VT1708S Analog [VT1708S Analog] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 0: NVidia [HDA NVidia], Gerät 1: VT1708S Digital [VT1708S Digital] Sub-Geräte: 0/1 Sub-Gerät #0: subdevice #0 Karte 0: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 1: Star [North Star], Gerät 0: USB-SPDIF Audio [USB-SPDIF Audio] Sub-Geräte: 0/1 Sub-Gerät #0: subdevice #0 ------------------------------------------------------------------------------------------------------------------------------------------ und nochmal die "mpd.conf": audio_output { type"alsa" name"Star" device"hw:1,0"# optional ------------------------------------------------------------------------------------------------------------------------------------------

Natürlich mit Copy & Paste, statt mit Screenshots - war wohl noch nicht ganz wach

Dein DAC wird dann gar nicht vom generischen USB-Audiotreiber angesprochen sondern von einem Kernelmodul namens "snd-usb-hiface" (M2Tech hiFace USB-SPDIF audio driver), aber das hilft auch nicht wirklich weiter, weil es bei diesem Treiber keinerlei Optionen, die man ändern könnte.

Damit bleibt neben deiner Nachfrage beim Hersteller und gegebenenfalls, wenn das zu nichts führt einem Bugreport bei Linux (vermutlich der alsa-devel Mailingliste), wohl vor allem die Möglichkeit an den USB-Optionen zu drehen (oft gibt es da auch einige unscheinbare Optionen im BIOS-Setup, die überraschende Auswirkungen haben).

Hoffe es ebenfalls. Fakt ist aber, dass er diesen Fehler erst seit ca. 3 Wochen hat. Vorher gab es keine Probleme.

Aber der Fehler ist nur mit dem PC aufgetreten, den du für den Freund gebaut hast oder hab ich das falsch verstanden?

Dein DAC wird dann gar nicht vom generischen USB-Audiotreiber angesprochen sondern von einem Kernelmodul namens "snd-usb-hiface" (M2Tech hiFace USB-SPDIF audio driver), aber das hilft auch nicht wirklich weiter, weil es bei diesem Treiber keinerlei Optionen, die man ändern könnte.

Wo siehst du denn DAS?
Kann ich nirgendwo sehen, bzw. ableiten.

Aber der Fehler ist nur mit dem PC aufgetreten, den du für den Freund gebaut hast oder hab ich das falsch verstanden?

Zuerst ja, aber inzwischen tritt er auch mit meinem Rechner auf. Vielleicht einfach ein blöder Zufall.
Habe jetzt jedenfalls erstmal alles für den TOSLINK Ein/Ausgang umgestellt.
Zum Glück hat mein (alter) PC das noch "von Hause aus"
Macht keine Probleme und klingt auch hervorragend.
Nur eine Kleinigkeit, die auch wieder etwas schräg ist: beim Format 24-bit/48Khz "flackert" ca. alle 7 Sekunden das Display mit der Anzeige der Samplerate ganz kurz. Bei allen anderen Samplerates bleibt's stabil.
Aber das ist natürlich nicht schlimm, damit kann ich leben.

Potiputt (Beitrag #31) schrieb:

Dein DAC wird dann gar nicht vom generischen USB-Audiotreiber angesprochen sondern von einem Kernelmodul namens "snd-usb-hiface" (M2Tech hiFace USB-SPDIF audio driver), aber das hilft auch nicht wirklich weiter, weil es bei diesem Treiber keinerlei Optionen, die man ändern könnte. Wo siehst du denn DAS? Kann ich nirgendwo sehen, bzw. ableiten.

Zuerst einmal habe ich mir in der Ausgabe von lsusb die einzige angesehen, die der DAC sein kann »Bus 001 Device 002: ID 04b4:931b Cypress Semiconductor Corp.« (alle anderen sind entweder Eingabegeräte, USB-Hubs und -Sticks) und mit Hilfe der ID kommt man dann leicht auf unterschiedliche Arten zum Ziel:
Ich habe zum Beispiel auf meinem PC geschaut welches Kernelmodul sich für diese ID zuständig fühlen würde, indem ich in der modprobe-Konfiguration nach der ID gesucht habe (ist nur quick & dirty, das geht auch eleganter):

$ modprobe -c | grep -i 04b4 | grep -i 931b alias usb:v04B4p931Bd*dc*dsc*dp*ic*isc*ip*in* snd_usb_hiface

Auch eine Internetsuche nach der ID und alsa oder linux hätte den Namen des Kernelmoduls zutage gefördert. Eine andere Möglichkeit wäre die Liste der geladenen Audiomodule auf deinem System gewesen:

# lsmod | grep "^snd"

Mit ein bisschen Erfahrung sticht einem in der Liste das entscheidende Kernelmodul sofort ins Auge.

ich würde dich ja noch weiter zum Problem ausfragen (ob das Problem 100%ig reproduzierbar auftritt und ob es noch immer keinen erkennbaren Zusammenhang zwischen dem Auftreten des Problems und der Kernelversion gibt), aber damit würde ich nur den falschen Eindruck erwecken, ich hätte noch irgendwelche Ideen auf Lager…

... aber damit würde ich nur den falschen Eindruck erwecken, ich hätte noch irgendwelche Ideen auf Lager…

Hey, der war jetzt aber richtig gut
Auch wenn ich es gefühlt schon ca. 36-mal gemacht habe, möchte ich dir nochmal für die Mühe danken, die du dir da gemacht hast !!
Bist du IT-Fachmann, oder einfach "nur" privater Profi ... ?
Habe zwar all die Befehle schon sehr oft gesehen, aber mein Linux-Wissen ist doch (noch) sehr ... äähh ... periphär
Bin aber schon lange fasziniert von der Philosophie und der Community die dahinter steht.

Und das mit dem M2Tech-Treiber erstaunt mich, weil ich kein Gerät dieser Firme besitze.
Witzigerweise hatte ich aber mal probeweise ein Hiface gehabt, als es noch keinen Linux-Treiber dafür gab.
Deswegen habe ich es damals wieder zurück geschickt.

Ok, dann warte ich jetzt auf eine Antwort vom Northstar-Chef, und höre erstmal gaaanz entspannt mit Toslink.
Habe das Gefühl, die "Bühne" ist ein bisschen breiter, aber nicht so tief, und insgesamt klingt es etwas ... entspannter?
Vielleicht auch nur Einbildung.



Und der musste jetzt sein

Bitte gerne und nein, ich bin kein Profi, nur computerinteressiert und schon recht lange GNU/Linux Anwender.

Was den Namen des Treibers, dessen Entwicklung unter dem Namen snd-usb-asyncaudio und noch außerhalb des Linuxkernels angefangen hat [1], angeht der richtet sich wohl nach den ersten Geräten, die der Treiber unterstützt hat. Dass dann ähnliche/kompatible Geräte dazugekommen sind ist nicht weiter überraschend.
Es geht beim Treiber ja auch nur um den Teil, der über USB mit dem PC kommuniziert und der Beschreibung des Treibers im Linuxkernel [2] nach liefert dieser Teil nur einen digitalen Audiodatenstrom im S/PDIF-Format und hat damit noch nicht viel mit dem Teil der das digitale Signal ins Analoge umsetzt (also dem eigentlichen DAC) zu tun.

Wenn du mit S/PDIF (Toslink) aus dem PC herausgehst, egal ob du nun den Onboardsound oder eine interne oder externe Soundkarte dazu verwendest umgehst du diesen Teil und nutzt nur den eigentlichen DAC-Teil, aber du verlierst damit auch die hervorstechende Eigenschaft der von diesem Treiber unterstützten Geräte, dass sie ihren Takt selbst erzeugen und damit auch vorgeben (müssen) wie schnell die Daten angeliefert werden.
(Bei S/PDIF egal ob elektrisch oder optisch weiß das sendende Gerät gar nicht vom Empfangenden, dem Empfänger bleibt also auf lange Sicht gar nichts anderes übrig als sich irgendwie dem Takt des Senders anzupassen.)

[1] https://github.com/panicking/snd-usb-asyncaudio
[2] https://cateee.net/lkddb/web-lkddb/SND_USB_HIFACE.html

Moin smutbert.

Bei S/PDIF egal ob elektrisch oder optisch weiß das sendende Gerät gar nicht vom Empfangenden, dem Empfänger bleibt also auf lange Sicht gar nichts anderes übrig als sich irgendwie dem Takt des Senders anzupassen

Mit Taktung meinst du "Clocking"? Das wäre natürlich nicht gut, weil die interne Clock des Wandlers sicherlich wesentlich besser ist.
Dachte, dass generell intern "reclockt" wird, egal von welchen Eingang die Daten kommen. Puh, muss noch viel lernen ...
Andererseits habe ich ja auch bis jetzt immer nur USB benutzt, daher musste ich mich auch nicht weiter mit diesem Thema beschäftigen.
Werde mir gleich mal die Links anschauen.

Thomas

Reclocking kann durchaus trotzdem stattfinden und wird es wahrscheinlich auch.
ich meine nur, dass der DAC bei Nutzung des S/PDIF-Eingangs nicht beeinflussen kann wie schnell die Daten geliefert werden. Fiele also rein hypothetisch der Takt des DAC im Schnitt minimal höher aus als der Takt des S/PDIF-Ausgangs des PC, dann gingen dem DAC früher oder später die Daten aus und im umgekehrten Fall würden sich die Audiodaten immer weiter aufstauen bis irgendwann der Zwischenspeicher voll ist. (Davon wie genau das verhindert wird habe ich allerhöchstens eine wage Ahnung.)

Bei der asynchronen USB-Verbindung dagegen kann der DAC seinen eigenen Takt verwenden, die Audiodaten so „anfordern“ wie er sie braucht und eventuelle Schwankungen problemlos mit seinem Zwischenspeicher ausgleichen.

Moin smutbert.

Neulich abends hörte ich noch Musi über Kopfhörer, mit dem Toslink-Eingang statt USB, aber irgendwie kam dabei nicht die richtige Stimmung auf.
Daraufhin stellte ich temporär wieder auf den USB-Eingang um, weil ich sowieso nur 16-bit Musi hörte.
Und siehe da - die "Magie" war wieder da
Scheint wohl doch besser zu klingen, habe aber keinen ausführlichen Test gemacht, sondern nur weiter glücklich gehört.
Damit stellt sich aber wieder die Frage, wie ich das Rausch-Problem löse.
Der Northstar-Chef hat sich leider noch nicht gemeldet ...
Werde mal parallel eine Mail an den deutschen Vertrieb schicken.
Aber so lange mir niemand sagt, dass der Wandler defekt ist, kann ich ja noch a bisserl probieren.
Natürlich könnte auch ein zwischengeschalteter "Reclocker" die Lösung sein, aber die kosten leider Geld ...
Und die richtig Guten sogar mind. 600 Euro.

Habe dann div. MPD-Wiki durchgelesen und dabei eine vielleicht entscheidende Entdeckung gemacht.
https://linux.die.net/man/5/mpd.conf

buffer_time <time in microseconds> This sets the length of the hardware sample buffer in microseconds. Increasing it may help to reduce or eliminate skipping on certain setups. Most users do not need to change this. The default is 500000 microseconds (0.5 seconds). period_time <time in microseconds> This sets the time between hardware sample transfers in microseconds. Increasing this can reduce CPU usage while lowering it can reduce underrun errors on bandwidth-limited devices. Some users have reported good results with this set to 50000, but not all devices support values this high. Most users do not need to change this. The default is 256000000 / sample_rate(kHz), or 5804 microseconds for CD-quality audio.

audio_buffer_size <size in KiB> This specifies the size of the audio buffer in kibibytes. The default is 2048, large enough for nearly 12 seconds of CD-quality audio. buffer_before_play <0-100%> This specifies how much of the audio buffer should be filled before playing a song. Try increasing this if you hear skipping when manually changing songs. The default is 10%, a little over 1 second of CD-quality audio with the default buffer size. max_output_buffer_size <size in KiB> This specifies the maximum size of the output buffer to a client. The default is 8192.

Da meine mpd.conf ja auf das nötigste reduziert ist, konnte ich diese Optionen gar nicht mehr sehen
Werde jetzt meine "Test-HD" wieder einbauen, um div. andere Distro's zu testen und dabei dann auch gleich diese Optionen checken.
Aber vorher wollte ich dich gern nochmal um Rat bitten - meinst du damit könnte ich vielleicht das Problem lösen, oder zumindest reduzieren?
Würde dann die Buffer-Grösse auf den Maximalwert setzen (8192 - um den Hochbit-Songs genug "Platz" zu lassen), und den "pre-play-buffer" auf 30% erhöhen ... oder auch mehr.
Natürlich immer nur vorsichtig in 10% Schritten.
Muss ich dabei überhaupt vorsichtig sein?
In einer Beschreibung steht, dass man da nur Änderungen machen soll, wenn man genau weiß, was man tut ...
Glaube das ich es schon verstanden habe, aber warum diese Warnung?
Traue mich kaum zu fragen, aber mache es doch - kann ich dabei meinen DAC schädigen??

Oder sollte ich es lieber über die "buffer_time" versuchen?

Oder lieber überhaupt nicht ??

Thomas