Aroio 5.XX - Diskussion Update-Funktion und Version

[Genera]

...
Die Tatsache dass man den Convolver stoppen müsste um ihn dann mit der passenden Samplingfrequenz neu starten müsste. Dies aber einige Sekunden dauert und das im Team zumindest niemand will. Wirft bei mir die Frage auf. Wie groß wäre der technische Aufwand um dieses Problem zu lösen? Was würde das den Endverbraucher kosten, und wäre der bereit das zu bezahlen? Dann, und erst dann sollte man sich das Urteil erlauben ob etwas sinnvoll wäre. Denn der Massstab sollte der Endverbraucher, sprich Hörer sein.

Der technische Aufwand wäre so groß, dass es bislang keine mir bekannte Software gibt, die eine FIR-Filterung on-the-fly umschaltet. Der Maßstab ist der Endverbraucher und wir haben ein sehr benutzbares Produkt im Rahmen sinnvollen Ressourceneinsatzes geschaffen. Wir haben uns viel Gedanken um Them wie Resampling etc. gemacht und sind zu dem Ergebnis gekommen, das vorliegt. Wem das nicht reicht, dem empfehle ich statt der Belehrerei einen Kurs in C-Programmierung und einen zu Linux-Systemen. Scheint ja alles nicht weiter wild zu sein.
...

Es gibt anschließend doch einen, wenn ich dem hier glauben kann:
https://www.ebay-kleinanzeigen.de/s-anz ... 2-172-2066

[((( atom )))]

Da gibt's nicht viel zu glauben, denn da steht einfach nicht geschrieben, dass on-the-fly ohne Aussetzen des Audiosignals umgeschaltet wird. Das war aber das Thema.

Da ich das Gerät kenne und so einige Telefonate mit Uli zum Thema der Umschalterei geführt habe, weiß ich, dass da BruteFIR gestoppt, die Filter der zuspielenden Rate entsprechend geladen und BruteFIR wieder gestartet wird. Dauert also ein paar Sekunden.

Wie gesagt, haben wir das intern ausführlich besprochen und sind zu dem Schluss gekommen, dass die Mehrheit der Kunden lieber ein unhörbares Resampling wird haben wollen, als eine Pause.

[((( atom )))]

@alx: Evtl. habe ich mich da verguckt. Der spotify Player startet, meldet zwar einen Fehler (der an sich nicht mehr kommen sollte, weil der Player auf das Netzwerk gewartet hat), aber beendet sich nicht. Es wäre jetzt tatsächlich noch interessant zu wissen, ob der Player denn funktioniert, oder nicht.

Ich hatte auf die Schnelle jedenfalls gesehen, dass der Player sich beendet hatte, aber das tut er, wenn man die Logs herunter lädt, weil dazu kurz die Soundkarte im Roh-Modus abgefragt werden muss.

[alx]

@atom
Ja, der player funktioniert für mich einwandfrei - auch wenn er die Fehler wirft. Folgendes wurde von mir nochmal aus Neugier probiert: Player-Service gestoppt und neu gestartet, dann blieben die zwei code99 Error Meldungen - wie erwartet - aus; falls das irgendwie hilft. Sag Bescheid, wenn noch irgendetwas von mir getestet werden soll. Die nächste Woche sitze ich wieder im Homeroffice und werde den player länger laufen lassen, falls da etwas passieren sollte, kann ich Bescheid sagen.

[((( atom )))]

Ja, es wäre ein Log vom Boot bis zum ersten Ton und dann direkt das Log gezogen aufschlussreich. Ich möchte natürlich idealerweise gebau verstehen, was da zeitlich passiert. Vielen Dank schon mal für die Infos bis hier!

[alx]

Gerne, hier...

Aroio_logs_99_boot2play.7z

(83.99 KiB) 1597-mal heruntergeladen

[Hironimus]

Hallo zusammen,

mir ist das nachfolgend Beschriebene aufgefallen, ob es hier zum Thema der "Beta" passt kann ich nicht einschätzen, da ich zeitgleich die Version 5.0.99 installiert und ein Probeabo neu Qobuz begonnen habe. Sollte es hier falsch platziert sein, bitte an die richtige Stelle im Forum verschieben.

Seit ich auf den Musikstreamingdienst Qobuz gewechselt habe und hochauflösendes Musikmaterial zuführe, ist mir eine Unstimmigkeit bei den Sampelrates aufgefallen.

Die Hörkette sieht so aus:
Raspberry Pi3B+ mit Allo Digione Signature — Vorverstärker/DAC Mytek Brooklyn DAC — Aktivlautsprecher

Betreibe ich den RasPi mit seinem aroioOS im Direct-Modus und spiele dem Player Squeeze zu, soll die dem RasPi zugeführte Sampelrate nativ verarbeitet werden. Das passiert bei mir auch, so werden die Samplerates bzw. Bitraten auf Zuführungsseite im LMS und auch am Eingang des Vorverstärkers korrekt angezeigt, siehe beispielhafte Bilder.


Da ich den RasPi aber mit dem Convolver betreiben möchte, habe ich mir ein Filter in AcourateCV generiert, dabei in Makro4 darauf geachtet, dass es in allen Samplerates erzeugt wird, und es in den RasPi auf eine Filterbank gelegt . Um sicherzustellen, dass alle Einstellungen im Aroio übernommen werden, habe ich immer auf übernehmen, Speichern und dann Neustart gedrückt.


Beim Abspielen der oben genannten Musikstücke wird mir jedoch am Eingang des Vorverstärkers IMMER die Samplerates 16/96kHz angezeigt. das kann aus meinem Verständnis nicht richtig sein, da sich die Bittiefe nicht verringern sollte und auch die Samplingfrequenz gleichbleiben sollte, da ja für jede ein Filter in Makro 4 generiert wurde.



Kann jemand aufklären oder eine Lösung aufzeigen?

Nachfolgend noch zwei Screenshots zu den Einstellungen, ggf.hilft das für die Beantwortung meiner Frage.



Anmerkung: Das 192kHz-Files kommt nicht von Qobuz, sondern von der NAS.

Danke & Gruß
Hironimus

[((( atom )))]

@Alx, vielen Dank!

Zu dem anderen Thema würde ich Hanno bitten, das mal eben zu erklären.

[Hironimus]

Hallo Zusammen,

einen Teil meiner Frage braucht nicht mehr beantwortet werden, hab nochmals drüber nachgedacht.
Da ich im Convolver-Modus auch mehrere Player betreiben kann, müssen diese natürlich auch auf eine gemeinsame Sampling-Frequenz gebracht werden, wie im Bus-Betrieb. Und diese ist bei mit auf 96kHz eingestellt, was ja auch durchgängig angezeigt wird. Also soweit alles ok.

Nur das Thema mit der Bittiefe ist mir noch nicht einleuchtend. Nehmen wir mein Beispiel, die Samplefrequenz ist auf 96kHz eingestellt, und es kommt ein Stream mit 24Bit/96kHz zum Aroio. Dieser wird dort verarbeitet, gefaltet und nun nur noch mit 16Bit/96kHz ausgegeben? Das wird mir zumindest am DAC-Eingang angezeigt.

Wie bereits geschrieben diese Beträge gerne verschieben, da sich nichts mit dem "Beta"-Thema hier zu tun haben.
Danke.

Viele Grüße
Hironimus

[((( atom )))]

Ich kann Dir das kurz erläutern:

Da der Convolver mit einem zu wählenden Filter gestartet werden muss, ist also seine Start-Samplingfrequenz vorher fest zu legen. Der Convolver rechnet das Eingangssignal durch das Filter (vereinfacht ausgedrückt wird beides miteinander multipliziert). Der Convolver ist nicht so entworfen, dass er nahtlos die Samplingfrequenz ändern kann. Unter anderem setzt er auf einem Bus-System (jack) auf, dass auch nur mit fester Rate arbeiten kann. Auch wenn sich einige das wünschen mögen, ist das nicht mal eben so programmiert.

Das man mehrere Zuspieler gleichzeitig akzeptieren kann, ist ein positiver Nebeneffekt der Nutzung eines Busses.

Zum notwendigen Resampling sei angemerkt, dass ein gutes Resampling gerade mal so noch messtechnisch nachzuweisen ist, zu hören ist da einfach nix mehr. Die Algorithmen sind längst so gut.

Die 16 Bit bei Nutzung von SPDIF haben historische Gründe. Gaaaanz weit vorne hier im Beta-Thread hatten Nutzer Probleme bei der Benutzung ihrer SPDIF-Karten und die Ursache war ein Bug im alsa Treiber, der die Nutzung von 24 Bit für SPDIF kaputt gemacht hat. Mir ist so, als sei dieser inzwischen behoben und es steht auf meiner ToDo-liste, mich mal damit zu beschäftigen. Die ToDo-liste bedeutet nach dem Release, auf das wir gerade hin arbeiten. Das wird also kommen, aber es wird dauern.