x3000 leichtes Piepen (Update: Stellungnahme 10.01.2019)

[Danwo]

Ich besitze die x3000RC seit ungefähr einer Woche. Bei mir piept da gar nichts. Läuft alles und klingt perfekt!

[anphex]

Habe mich auch seit bald einem Jahr mit dem gelegentlichen Fiepen über USB abgefunden gehabt. Seitdem ich aber etwas mit Musik angefangen habe, ist es erstaunlich oft aufgetreten. Besonders beim durchstöbern von drum samples. Sogar der standarmäßige Taktgeber Click von Studio One löst absolut jedes Mal dieses Fiepen aus. XLR Input genauso. Sehr frustrierend. Gibt es nach wie vor keinen Fix?

[cryptochrome]

Hallo,

ich habe mir im März diesen Jahres ein Paar X-3000 RC gekauft und diese zunächst als Regallautsprecher verwendet. Da ist mir nichts aufgefallen. Seit einigen Wochen sind die Boxen nun aber auf meinen Schreibtisch umgezogen und dienen dort als Nahfeldmonitore. Also auf Ohrenhöhe, Sitzabstand etwa 70 cm.

Das Fiepen ist _extrem_.

Was ich mich ernsthaft frage: Wie kann es sein, dass Nubert diese Boxen weiterhin verkauft, obwohl das Problem seit mind. 2019 bekannt ist (weiter hab ich im Thread nicht zurückgeblättert) und offenbar nie gelöst wurde? Das finde ich echt grenzwertig.

Ich würde gerne wissen, ob ich von dem am 10. Januar 2019 von @R. Steidle hier im Thread gemachten Rückgabeangebot noch Gebrauch machen kann. Da ich die Boxen schon seit März habe, gehe ich mal nicht davon aus.

[R. Steidle]

Wenn Sie ernsthaft unzufrieden sind, kontaktieren Sie bitte die Hotline und bitten Sie um Rückgabe!

[.Robert.]

Hallo,

ich habe seit dem 01.10.2021 ein Paar nuPro X-3000 RC. Nach der anfänglichen Begeisterung über den großartigen Klang leider die Ernüchterung. Leider piept auch bei mir ein Lautsprecher deutlich. Da ich diese ebenfalls als Schreibtischlautsprecher am PC nutze ist das piepen wirklich störend. Was mich wundert ist, dass es bei mir immer der selbe Lautsprecher ist, egal ob dieser Master oder Slave konfiguriert ist. Des Weiteren spielt es keine Rolle ob per Kabel oder kabellos verbunden. Auch ein hochwertigeres Coaxialkabel wurde getestet.
Sobald man den besagten Lautsprecher anschaltet beginngt das piepen. Auffällig ist auch, dass dieser Lautsprecher ein deutlich lauteres Grundrauschen hat. Der andere Lautsprecher dagegen ist so gut wie still und nicht wahrnehmbar.
Ist es möglich nur den einen Lautsprecher zu tauschen um auszuschließen das es sich bei dem einen um ein "Montagsgerät" handelt?

[R. Steidle]

Das Geräusch, um das es in diesem Thread geht, ist definitiv nicht an einen Lautsprecher gebunden, tritt nicht gleich nach dem Einschalten auf, ist nicht permanent vorhanden und auch nicht mit einem erhöhten Grundrauschen verbunden. Deshalb würde ich vorsichtig darauf tippen, dass es sich hierbei um ein anderes Phänomen handelt. Wenn möglich, bitte aufnehmen! Bitte nach Möglichkeit außerdem systematisch potentielle Fehlerquellen (Verkabelung, Quelle/Eingang) durchtesten, um eine externe Ursache auszuschließen. Bringt das nichts, würde ich zunächst einen Tausch versuchen. Dazu bitte an der Hotline melden.

[.Robert.]

Guten Morgen,

vielen Dank für die schnelle Antwort. Das es immer nur bei einem Lautsprecher auftritt hat mich auch stutzig gemacht.
Aufgenommen habe ich es. Kann man Audiofiles direkt hier im Thread hochladen oder soll ich mich direkt an die Hotline wenden?

[R. Steidle]

Wenn es nicht zu viele Umstände macht, würde ich interessehalber gerne kurz reinhören: r.steidle@nubert.de. Natürlich können Sie sich gerne parallel direkt an die Hotline wenden.

[engineer]

Gibt es neues Erkenntnisse hinsichtlich Unterschieden RC und nicht-RC?
Ich finde die 4000er interessant wegen des AES und der mehrfachen S/PDIF Eingänge.

Wenn das nur bei wireless auftritt, wäre das akzeptabel.

Habe den thread mal überflogen und muss einen Kommentar abgeben wegen "Qualitätssicherung":

Wenn die Hersteller von Chips mal so vorgingen, wie sie es könnten, nämlich bei der Endkontrolle für ALLE Chips BSCAN verwenden, im Design vollständige Simulationen der Funktionen durchführen und einen mehrfach abgesicherten Designprozess etablieren würden, wie sie das z.B. für Auftragsentwicklungen in der MIL tun - dann hätten die Kunden, also die Nutzer solcher Chips mal direkt 50% weniger solcher dubiosen Probleme. Wenn dann noch die Hersteller der Compiler für diese DSPs und Controller eine saubere Softwareentwicklung aufzögen und ihre Optimierungen, mit denen sie kleinen Code produzieren, umfangreich für alle Hardware und Randbedingungen testen würden, gäbe es nochmal weniger bugs.

Allerdings würden dann Chips das Doppelte und die Software das Dreifache kosten und DSP-basierte Systeme wären nicht so billig, wie sie sind. Vor allem würden neue Produkte nicht so rasch in den Markt kommen. Da aber die Kunden immer das Billigste kaufen, sind die Hersteller gezwungen, kostenoptimiert zu entwickeln und Neues rasch zu vermarkten, weil sie sonst gar nichts verkaufen, sondern die Konkurrenz. Und entwickelt wird natürlich dort, wo es am Billigsten ist (wobei es nicht selten auch deshalb billig ist, WEIL dort mit Unerfahrenen hoppla-hopp gebaut wird).

Also leben wir Entwickler mit defektiösen Chips, falscher Doku, mangelnden Treibern und SW-bugs ohne Ende. Die DSP- und Controller-Ecke ist da noch weitgehend gut aufgestellt, aber gehe mal her und nehme ein SOC oder komplexere FPGA-Hardware in Betrieb. Die ersten Chips haben immer unentdeckte Bugs und die SW unterstützt sie bis zum EOL oft nicht vollständig. Andauernd kommt ein update wegen irgendwas raus.

Chips und PCB-Subsysteme für den Konsumerbereich sind so derart unter Preisdruck, dass sie besonders viele Macken haben. Wenn man sich überlegt, was auf dem Weg vom PC zur Membran alles passieren muss (insbesondere bei wireless) darf man sich nicht wundern, wenn es irgendwo zickt.

Was das Problem selber angeht, fallen mit gleich mehrere Gründe ein, warum es ziept - allerdings macht es keinen Sinn, ins Blaue hinein zu raten, weil die Entwickler das Naheliegende sicher alles abgetestet haben. Das Einzige, was man sagen kann, ist dass es zu 99% ein timing Problem in einer SW sein dürfte, weil es sporadisch und flächendeckend auftritt: Da wird irgendwas probiert, abzuschalten und überholt etwas anderes und es bleibt unvollständig, oder ein Vorgang wird zwar richtig durchgeführt, aber elektrisch nicht sauber beendet, z.B. ein PDM-Signal nicht richtig gemutet oder es wird etwas zu einem ungünstigen Zeitpunkt abgeschaltet und ein Elektronikteil schwingt weiter, z.B. eine H-Brücke, die auf irgendwas regelt. Gfs wird auch fälschlich ein analoger Chip-Eingang aktiv und fängt sich was, oder es geht wieder irgend ein Chip in den Stromsparmodus, wo er es nicht soll. All so Zeug hatte ich schon in Projekten.

[R. Steidle]

Gibt es neues Erkenntnisse hinsichtlich Unterschieden RC und nicht-RC?

Meines Wissens nach gibt es da keine Unterschiede.