NUX NAI-24 – Analiza techniczna implementacji USB i oprogramowania układowego

Chyba każdy już zdążył zauważyć, że segment budżetowych interfejsów audio przeżywa w ostatnich latach bezprecedensowy rozkwit. I nie mówię tu o furorze, jaką zrobiły sprzęty Focusrite. Pretendentów do posmakowania tortu jest coraz więcej, a urządzenia wyceniane w okolicach tysiąca złotych przestały być traktowane jako prowizoryczne rozwiązania dla początkujących. Wręcz można powiedzieć, że stały się pełnoprawnymi narzędziami pracy dla twórców internetowych, instrumentalistów i domowych producentów muzycznych.

W te rynkowe realia próbuje wpisać się NUX NAI-24 – kompaktowy interfejs wyposażony w zestaw wejść mikrofonowo-liniowych, sprzętowy loopback oraz rozbudowane manipulatory frontowe. NUX miał już swoją premierę dosłownie chwilę temu w formie całkiem przemyślanych mikro-monitorów, a sama marka Cherub/NUX dotychczas była powszechnie kojarzona raczej z cyfrowym modelowaniem gitarowym. Niemniej model NAI-24 zwiastuje jak sądzę próbę zajęcia pozycji w segmencie uniwersalnych narzędzi rejestracji dźwięku właśnie do 1000 zł. I to właśnie sobie tutaj zweryfikujemy, choć zapowiedzieć muszę na wstępie, że będzie tu sporo fragmentów z kodem i zabawy terminalem.

Testowany sprzęt został użyczony przez jednego z czytelników portalu. Jeśli posiadacie sprzęt audio, którego jeszcze nie ma w bazie, i zależy Wam na jego pełnej, niezależnej weryfikacji metrologicznej oraz rzetelnym odsłuchu – serdecznie zapraszam do zgłoszenia go na oficjalne pomiary laboratoryjne.

Działalność Audiofanatyka oraz rozwój zaplecza pomiarowego można wesprzeć bezpośrednio: zamawiając kable z mojej manufaktury lub stawiając wirtualną kawę na Buycoffee.to 💜

Geneza testu i oczekiwania wobec standardu UAC2

Egzemplarz testowy został dostarczony prywatnie przez czytelnika jako fabrycznie nowa, zaplombowana sztuka pochodząca bezpośrednio z bieżącej dystrybucji sklepowej. Pozwoliło to na weryfikację urządzenia w stanie w 100% dziewiczym – dokładnie w takiej formie, w jakiej trafia ono z półki magazynowej do rąk klienta końcowego.

Współczesny rynek interfejsów audio opiera się na fundamencie, jakim jest standard USB Audio Class 2.0 (UAC2). Wbrew powszechnemu, błędnemu przekonaniu, nie jest to żadna specyficzna funkcja systemów Linux czy fanaberia programistyczna. UAC2 to otwarty, międzynarodowy standard opracowany przez organizację USB-IF (USB Implementers Forum), który definiuje uniwersalny protokół bezstratnej transmisji wielokanałowego dźwięku i precyzyjnej synchronizacji zegara bez konieczności stosowania jakichkolwiek dedykowanych sterowników zewnętrznych.

To właśnie na pełnej zgodności z UAC2 bazuje dzisiaj cały ekosystem urządzeń profesjonalnych i mobilnych: od systemów macOS i Linux, przez tablety iPad (iPadOS), smartfony, aż po autonomiczne stacje robocze, samplery sprzętowe i cyfrowe miksery estradowe. Urządzenie w pełni zgodne ze specyfikacją UAC2 po prostu podłącza się do portu i rozpoczyna pracę. Sprzęt studyjny uznanych marek w środowisku laboratoryjnym zgłasza się natychmiast w trybie Plug and Play. Oczekiwania wobec NUX NAI-24 były w tym względzie identyczne. Rzeczywistość laboratoryjna przyniosła jednak twarde zderzenie z błędem implementacyjnym.

Zachowanie urządzenia w warunkach laboratoryjnych

Po fizycznym podłączeniu interfejsu do portu magistrali xHCI i skierowaniu na niego pierwszego strumienia audio, tor wyjściowy nie wygenerował czytelnego sygnału, lecz ciągły potok artefaktów cyfrowych. Zniekształcenia transmisyjne miały charakter permanentnego digital shreddingu, przypominającego zdesynchronizowaną fonię kodowanych transmisji telewizyjnych z dawnych lat.

Co więcej, odtwarzany materiał podlegał nieustannym wahaniom tempa i tonacji – utwory naprzemiennie gwałtownie przyspieszały i zwalniały w losowych odstępach czasu lub od wciskanych przycisków.

Weryfikacja zachowania sprzętu na alternatywnych przewodach USB oraz odrębnych kontrolerach płyty głównej dała identyczny rezultat. Aby wykluczyć usterkę na poziomie miksera systemowego czy serwera PipeWire, diagnostykę przeniosłem bezpośrednio na poziom jądra systemowego oraz podsystemu ALSA.

Odpowiedź na pytanie o źródło anomalii pojawiła się w rejestrze zdarzeń jądra praktycznie natychmiast po zainicjowaniu połączenia:

[  408.799770] usb 5-2: new high-speed USB device number 2 using xhci_hcd
[  408.923017] usb 5-2: New USB device found, idVendor=3703, idProduct=2000, bcdDevice= 1.01
[  408.923754] usb 5-2: config 1 has an invalid interface number: 4 but max is 3
[  408.923759] usb 5-2: config 1 has no interface number 3
[  408.925217] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  408.925220] usb 5-2: Product: NUX NAI-24
[  408.925222] usb 5-2: Manufacturer: NUX
[  408.925224] usb 5-2: SerialNumber: 241108155051
[  408.936422] usb 5-2: Quirk or no altset; falling back to MIDI 1.0

Kernel Linuksa, działający w oparciu o ścisłe egzekwowanie oficjalnych wytycznych USB-IF, zarejestrował błąd w tablicy deskryptorów w pamięci Flash urządzenia. Wersja oprogramowania układowego (raportowana w polu rewizji jako bcdDevice 1.01) zawiera wadę strukturalną.

Zgodnie ze specyfikacją USB, jeśli urządzenie deklaruje obsługę czterech interfejsów (bNumInterfaces = 4), muszą one posiadać ciągłą numerację w przedziale od 0 do 3.

Weryfikacja struktury urządzenia poprzez narzędzie lsusb ujawnia przyczynę odrzucenia pakietu przez system:

  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0150
    bNumInterfaces          4
    bConfigurationValue     1

    Interface Descriptor:
      bInterfaceNumber        0
      bInterfaceClass         1 Audio (Control Device)

    Interface Descriptor:
      bInterfaceNumber        1
      bInterfaceClass         1 Audio (Streaming Capture)

    Interface Descriptor:
      bInterfaceNumber        2
      bInterfaceClass         1 Audio (Streaming Playback)

    Interface Descriptor:
      bInterfaceNumber        4
      bInterfaceClass         1 Audio (MIDI Streaming)

W strukturze urządzenia interfejs numer 3 w ogóle nie istnieje – w kodzie źródłowym nastąpił przeskok bezpośrednio z indeksu 2 na 4. W rezultacie parser jądra traktuje interfejs 4 jako niezgodny ze zadeklarowanym zakresem i odrzuca go, odcinając komunikację z powiązanymi zasobami.

Uszkodzona pętla synchronizacji zegara (Feedback Endpoint)

Błąd deskryptora to jednak zaledwie wstęp do właściwego problemu, który uniemożliwia prawidłowy odsłuch. Prawdziwa przyczyna rzężenia toru audio i pływania tempa odtwarzania leży w niesprawnej pętli synchronizacji zegara transmisyjnego.

Bezpośredni zrzut parametrów aktywnego strumienia w podsystemie ALSA ujawnia architekturę logiczną NAI-24:

NUX NUX NAI-24 at usb-0000:10:00.4-2, high speed : USB Audio

Playback:
  Status: Stop
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 4
    Endpoint: 0x01 (1 OUT) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 32
    Channel map: FL FR FC LFE
    Sync Endpoint: 0x81 (1 IN)
    Sync EP Interface: 2
    Sync EP Altset: 1
    Implicit Feedback Mode: No

Capture:
  Status: Stop
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 0x83 (3 IN) (SYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 32
    Channel map: FL FR

Odtwarzanie realizowane jest w trybie asynchronicznym (ASYNC). W takim modelu to nie komputer narzuca taktowanie, lecz przetwornik interfejsu dyktuje tempo przesyłu danych za pośrednictwem dedykowanego punktu końcowego sprzężenia zwrotnego – w tym przypadku Sync Endpoint 0x81. Kontroler NAI-24 przesyła w mikroramkach pakiety informujące system, ile próbek powinien w danym ułamku milisekundy nadać.

W obecnym kodzie NUX-a logika raportowania zegara w punkcie 0x81 działa w sposób wadliwy. Mikrokontroler wysyła do systemu gwałtownie zmieniające się wartości taktowania. Sterownik systemowy stara się na bieżąco dostosować transfer do napływających informacji: gdy otrzymuje informację o konieczności przyspieszenia – wypycha próbki z naddatkiem, gdy wartość drastycznie spada – gwałtownie hamuje.

Ponieważ fizyczny oscylator sprzętowy przetwornika nie zmienia swojej częstotliwości w tak skokowy sposób, wewnętrzny bufor FIFO w ułamku sekundy naprzemiennie ulega przepełnieniu (overflow) i opróżnieniu (underflow). Powstające gubienie i dublowanie próbek PCM odpowiada bezpośrednio za drastyczne zniekształcenia dźwięku oraz wrażenie falowania tempa.

Dodatkowym utrudnieniem konstrukcyjnym jest brak alternatywnego profilu dwukanałowego dla toru wyjściowego – interfejs narzuca sztywno format 4-kanałowy w słowie 32-bitowym (S32_LE), co przy zaburzonej synchronizacji potęguje problem.

Weryfikacja procedury serwisowej DFU

W normalnych warunkach konsumenckich naturalną reakcją na takie zachowanie sprzętu prosto z pudełka byłby natychmiastowy zwrot do sprzedawcy. Jako że celem nadrzędnym była rzetelna ocena możliwości urządzenia, podjęto próbę weryfikacji oprogramowania układowego na oficjalnej ścieżce wsparcia producenta.

Narzędzie aktualizacyjne NUX udostępniane jest w postaci pliku wykonywalnego dla systemu Windows. Aby wykluczyć jakiekolwiek anomalie środowiskowe i zapewnić maksymalne bezpieczeństwo procedury, przygotowano dedykowaną, fizyczną stację roboczą z natywną instalacją systemu Windows.

Cały proces przeprowadzono ściśle według oficjalnych wytycznych producenta:

1. Pobrano pakiet NUX Device Updater oraz najnowszy oficjalny wsad oprogramowania dla modelu NAI-24.
2. Wprowadzono interfejs w tryb programowania DFU (kombinacja przycisków MUTE oraz OUT 3/4 podczas podłączania zasilania USB).
3. Przeprowadzono pełen cykl programowania kości Flash w oprogramowaniu serwisowym.
4. Wykonano sprzętową weryfikację zapisu (kombinacja MUTE + OUT 3/4 + LOOPBACK). Dioda STEREO zamrugała trzykrotnie, potwierdzając bezbłędny zapis pamięci nieulotnej.

Po ponownym wpięciu urządzenia do toru pomiarowego zachowanie sprzętu nie uległo jednak zmianie. Wyjaśnienie tego faktu przynosi punkt 7 oficjalnej instrukcji aktualizacji:

„7. Confirm Firmware Version: If you’re using Windows, launch the ASIO driver, go to the INFO page, and check the Serial No. — it should be displayed as 241108xxxxx. (Windows Only)”

Wystarczy porównać tę informację z pierwotnym zrzutem rejestru jądra, wykonanym przed rozpoczęciem jakichkolwiek prób aktualizacji:

[  408.925217] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  408.925220] usb 5-2: Product: NUX NAI-24
[  408.925222] usb 5-2: Manufacturer: NUX
[  408.925224] usb 5-2: SerialNumber: 241108155051

Oprogramowanie NUX-a w polu numeru seryjnego koduje datownik i godzinę kompilacji oprogramowania układowego. Egzemplarz fabryczny posiadał wsad skompilowany 8 listopada 2024 roku o godzinie 15:50:51 (241108155051). Procedura aktualizacyjna wgrała tymczasem do pamięci dokładnie tę samą, najnowszą dostępną obecnie kompilację kodu.

Oznacza to, że obecna rewizja oprogramowania NUX NAI-24 nadal zawiera opisaną wadę deskryptora oraz niepoprawnie funkcjonującą pętlę taktowania UAC2. Zastosowanie dedykowanego sterownika ASIO na platformie Windows stanowi jedynie programowe obejście problemu na poziomie systemu operacyjnego, lecz nie naprawia źródłowej usterki kodu zaszytego w urządzeniu.

Metodologia pomiarowa i perspektywa Windows

Dlaczego w zaistniałej sytuacji procedura testowa nie została przeniesiona na platformę Windows?

Fundamentem mojego portalu jest ścisła powtarzalność warunków testowych. Wszystkie urządzenia audio w tutejszych testach poddawane są analizie w identycznym, standaryzowanym środowisku. Czynienie wyjątku dla jednego modelu i przenoszenie pomiarów na inną platformę systemową wprowadziłoby zmienne niemożliwe do skompensowania i zaburzyło porównywalność wyników z pozostałymi urządzeniami w bazie.

Przede wszystkim jednak profesjonalne narzędzie studyjne powinno bronić się poprawnością implementacji standardów przemysłowych na poziomie sprzętowym, a nie wyłącznie obecnością zewnętrznych nakładek sterownikowych.

Szkoda, ponieważ od strony czysto fizycznej NUX NAI-24 zapowiada się na konstrukcję niezwykle przemyślaną. Jakość obudowy, ergonomia manipulatorów, obecność funkcji loopback oraz ogólny projekt interfejsu sugerują duży potencjał w swoim segmencie cenowym. Niestety, w obecnym stanie oprogramowania układowego pełne testy elektroakustyczne toru analogowego (THD, zniekształcenia intermodulacyjne, dynamika i liniowość) nie mogły zostać przeprowadzone w sposób rzetelny.

Środowisko jądra Linuksa nie jest w tym równaniu żadną przeszkodą ani niszową fanaberią, lecz bezwzględnym mikroskopem diagnostycznym – zamiast tolerować niechlujstwo kodu układowego za pośrednictwem dedykowanych łatek w sterowniku, bezlitośnie obnaża rzeczywisty stan implementacji standardów, do których dochowania zobowiązał się producent.

Podsumowanie i ocena

NUX NAI-24 w obecnej rewizji oprogramowania układowego (241108) wykazuje istotną wadę implementacji standardu USB Audio Class 2.0. Błąd w tablicy deskryptorów oraz brak stabilnej synchronizacji w asynchronicznej pętli taktowania uniemożliwiają poprawną pracę w otwartych środowiskach studyjnych oraz na platformach mobilnych i autonomicznych nieobsługujących dedykowanego instalatora sterowników Windows.

Z tego względu obecny stan urządzenia zmusza do wystawienia jedynej możliwej oceny: Pingwinka w kostce lodu.

Jest to nota odzwierciedlająca obecną, fabryczną niesprawność urządzenia w ramach rygorystycznego standardu UAC2. Niniejsza publikacja oraz zawarte w niej zrzuty diagnostyczne stanowią jednak otwarty materiał badawczy, z którego inżynierowie NUX/Cherub mogą bezpośrednio skorzystać przy przygotowywaniu stosownej łaty oprogramowania układowego.

Na szczęście korekta numeracji interfejsów w deskryptorze oraz ustabilizowanie raportowania zegara w punkcie końcowym 0x81 to kwestia wyłącznie programowa. W momencie, gdy producent udostępni wersję oprogramowania w pełni przywracającą zgodność ze standardem UAC2, z prawdziwą przyjemnością powrócę do NAI-24, aby poddać jego tor analogowy pełnej procedurze pomiarów elektroakustycznych. Na ten moment urządzenie musi jednak poczekać na ruch ze strony programistów marki.

Sprzęt na dzień pisania recenzji dostępny jest za 990 zł.

Dane techniczne

Specyfikacja zaczerpnięta z jednego ze sklepów:

Wejście mikrofonowe:

• Zakres dynamiki: 114 dB (A-ważony)
• Pasmo przenoszenia: 20-20000Hz ± 0,1 dB
• THD+N: 0,002%@-1dBFS (przy minimalnym wzmocnieniu)
• EIN: -126dB (A-ważony)
• Maksymalny poziom wejściowy: 6 dBu (przy minimalnym wzmocnieniu)
• Zakres wzmocnienia: 5,4-63 dB
• Impedancja wejściowa: 2,4 kΩ

Wejście liniowe:

• Zakres dynamiki: 114 dB (A-ważony)
• Pasmo przenoszenia: 20-20000Hz ± 0,12 dB
• THD+N: 0,003%@-1dBFS (przy minimalnym wzmocnieniu)
• Maksymalny poziom wejściowy: 26 dBu (przy minimalnym wzmocnieniu)
• Zakres wzmocnienia: -12,6-45 dB
• Impedancja wejściowa: 21kΩ

HI-Z:

• Nominalny poziom wejściowy: -10dBu
• Impedancja wejściowa: 1MΩ

1L/2P:

• Zakres dynamiki: 112 dB (zbalansowany, 600 Ω.A-ważony)
• Pasmo przenoszenia: 20-20000Hz ± 0,5 dB
• Maksymalny poziom wyjściowy: +12,4 dBu (zbalansowany, 0 dBFS)
• THD+N: 0,0015%@-1dBFS
• Impedancja wyjściowa: 580Ω

3L/4P:

• Zakres dynamiki: 112 dB (zbalansowany, 200 kΩ, A-ważony)
• Pasmo przenoszenia: 20-20000Hz ± 0,1 dB
• THD+N: 0,001%@-1dBFS
• Maksymalny poziom wyjściowy: +18,4 dBu (zbalansowany, 0 dBFS)
• Impedancja wyjściowa: 240Ω

WYJŚCIE SŁUCHAWKOWE:

• Zakres dynamiki: 104 dB (A-ważony)
• Pasmo przenoszenia: 20-20000Hz ± 0,25 dB
• THD+N: 0,005%@-5dBFS
• Moc wyjściowa: 30mW@32Ω
• Wymiary: 194(dł.)x128(szer.)x67(wys.)mm
• Waga: 722g