Voyage MPD

[marsboer]

Har undersøkt litt rundt dette med interrupts, NRPACKS og bitrater, og på mitt Intel-baserte system med M2Tech HiFace Two gjelder følgende:

- Interrupts per sec er vanligvis ~2000 int/s for USB-busens IRQ, men går av og til ned til 1000 int/s. Det hender av og til at jeg ser verdier i mellom også, men dette er kun i korte øyeblikk så jeg antar at dette egentlig skyldes en overgang fra 1000 til 2000 i løpet av intervallet det måles på slik at gjennomsnittet forskyves.

- NRPACKS påvirker ikke antall interrupts/sec i det hele tatt på mitt system. Siden NRPACKS regulerer antall fulle frames/pakker per URB virker det derfor som om utsending av URB ikke er styrende for generering av en interrupt. Enten det, eller at NRPACKS verdien faktisk enten overstyres per device eller ignoreres.

- Interrupts/sec varierer ikke avhengig av bitrate. Om jeg spiller 24bit/192kHz eller 16bit/44.1kHz spiller ingen rolle. Det er alltid 2000 eller alternativt 1000 av og til.


I den forbindelse åpner det seg noen spørsmål for min del:
- Hvorfor er antall interrupts av og til 1000, men som regel 2000?
Min teori er at siden asynkron USB opererer med to isokrone kanaler, en i hver retning, så blir antallet interrupts også doblet for gjeldende IRQ. Med andre ord at hver isokrone kanal har 1000 int/sec og at den ene kanalen ikke nødvendigvis er aktiv til ethvert tidspunkt under avspillingen.

eller

Systemet mitt består av en dual core CPU med hyper threading. Antallet interrupts dobles fordi det er to fysiske kjerner. Den logiske bristen er imidlertid at linux ser fire logiske CPUer på grunn av hyperthreading. Det må i såfall være noe logikk som skiller på dette for interrupt generering.

- Hvorfor er antall interrupts akkurat 1000/2000?
Her har jeg flere teorier:
I følge dokumentasjonen for isokron USB lages det en pakke hvert ms som igjen kan ha 8 pakker for USB 2.0. Det er derfor naturlig å relatere akkurat 1000 interrupts til kreasjonen av en full frame. Noe som i såfall vil si at det dannes en interrupt bare for fulle pakker og ikke for mikroframes.

eller

Dette styres helt og holdent av enheten selv. Med andre ord vil interruptratene variere med hvilket USB-lydkortet som tilkobles.

I følge dokumentasjonen på MSDN gjelder følgende:

How often does the endpoint send or receive data?
The Interval member is used to determine how often the endpoint can send or receive data. The device sets that value and the client driver cannot changed it. The USB driver stack uses another number to determine the frequency with which it inserts isochronous packets into the data stream: the polling period, which is derived from the Interval value.

http://msdn.microsoft.com/en-us/library/windows/hardware/hh406225(v=vs.85).aspx

Slik jeg forstår dette er det enheten selv som setter et intervall for sending og mottak av data, og at dette ikke kan styres av driverprogramvaren i det hele tatt.
Spørsmålet er om dette intervallet har noe med interrupts å gjøre i det hele tatt. Det vil si om det å sende data = generasjon av intterupt i den kontekst det snakkes om her.

Noen som har noen innspill?
Hvilke interruptrater observerer dere, og er den avhengig av USB-lydkort, datarate og NRPACKS?

Den enkleste måten jeg har funnet for å observere dette er:

procinfo -d -n 1

Da får man ut blant annet CPU-bruk, datarater på nettverk og interrupts fordelt på IRQ kalkulert som et gjennomsnitt over et intervall på ett sekund. Installer programmet med "apt-get install procinfo".

 

[Oblivion]

irq   0:         10                      irq  36:          0
irq   7:          0                      irq  39:          0
irq  11:          0                      irq  40:          0
irq  21:         11                      irq  42:          0
irq  24:       2001                      irq  43:          0
irq  25:        143                      irq  62:          0
irq  29:          2                      irq  76:          0
irq  35:          0                      irq 133:          0

IRQ21 = intern SPDIF
IRQ24 = WaveIO USB adapter
IRQ25 = ObliUSB adapter

Dette er med NRPACKS = 16

Med NRPACKS = 1 øker ObliUSB til nesten 1000 interrupts pr. sekund (mot ca. 140).
Med NRPACKS = 32 eller 64 reduseres interrupts for WaveIO ned til 1700.
For WaveIO synker interrupt raten jevnt etter som NRPACKS blir økt.

Årsaken til at du ikke ser noen særlig forskjell på interrupt raten med forskjellige samplerater og bit dybder skyldes i hovedsak USB adapteret...
Det er fordi USB adapteret (som du er inne på) er deklarert som et 32bit interface med gitte settinger og linux / ALSA sender data basert på dette.
Jeg jobber nå med å få deklarert USB adapteret som 16bit, 24bit og 32bit med optimaliserte settinger slik at linux / ALSA velger alternative "interface" mot det samme USB adapteret avhengig av hva som spilles.
Da vil interrupt raten bli helt forskjellig avhengig av hva som spilles av samplerater og bit dybder.
De ca. 140 interrupts jeg nå har pr. sekund bør kunne gå ned med en faktor på 2 eller 4.

Hvis du prøver med NRPACKS = 64 og MAX_PACKS = 256 så burde også det USB adapteret du bruker få redusert interrupt raten merkbart.
Misstenker at endel USB 2.0 adaptere "bruker" SPEED_FULL metoden eller SPEED_LOW metoden for data overføringen da noe slikt er omtrent det eneste som skulle kunne generere interrupt rater på opp mot 2000 i sekundet.

 

[Oblivion]

Litt mer informasjon som kan hjelp:

Koblet opp QNKTC 1.1 og Light Harmonic Da Vinci DAC og vekslet mellom dem og WaveIO og ObliUSB.

ALSA device list:
#0: Kirkwood S/PDIF
#1: Objective Development DG8SAQ-I2C at usb-orion-ehci.0-1, high speed
#2: Light Harmonic Da Vinci Light Harmonic Da Vinci 1V78 at usb-orion-ehci.1-1, hig

Laget en "feil situasjon" slik at USB adapterne forble oppkoblet, men uten at det spiller musikk.
Da fikk jeg se interrupt raten de forskjellige adapterne forårsaker på "tomgang".

Kirkwood S/PDIF generere da IKKE interrupt (ikke på USB).
QNKTC 1.1 genererer 1014 interrupt pr. sekund
WaveIO genererer 1014 interrupt pr. sekund
ObliUSB genererer 126 interrupt pr. sekund
Da Vinchi genererer 40 interrupt pr. sekund




Dermed tror jeg at det kan slås fast at QNKTC 1.1 og WaveIO (og de fleste andre såkalte USB 2.0 adaptere på markedet) bruker en uheldig måte å overføre data på.
Det kan enten være USB adapter som bruker SPEED_FAST eller SPEED_SLOW metode, eller ALSA / linux som ikke detekterer USB adapterne riktig som USB 2.0 og bruker SPEED_FAST eller SPEED_LOW metoden...

Jeg fikk nå også verifisert at ObliUSB kan optimeres med en faktor på 2 - 4 slik at "tomgangs" interrupt raten kommer ned i 40 eller lavere pr. sekund.
Og også verifisert at når jeg spiller så er det kun en økning på 17 interrupt pr. sekund (fra 126 til 143), og at vidre optimering trygt kan vente til ObliUSB adapteret får ny firmware


Basert på det jeg har prøvd ut tidligere så kan de USB adapterne som fungerer med 1000 til 2000 interrupt optimeres ved å forandre på ALSA parametrene.
Typisk ned mot 1000 interrupt og med bare NRPACKS og MAX_PACKS i allefall ned til 1400 - 1500...


Forstår også nå at uten slike USB 2.0 Audio adaptere (som ikke har 1000 interrupt tomgang) som jeg har og også har hatt og brukt i nærmere to år så har det vært to helt forskjellige og ikke sammenlignbare konsepter.

 

[marsboer]

Da har jeg lest USB standardspesifikasjonsdokumenter til øyet ble stort og vått, og selv om det stod utrolig mye nyttig informasjon fant jeg ingenting som gikk på hva som egentlig genererer interrupt. Jeg gikk derfor til neste steg - sniffing på USB-busen. Dette er heldigvis veldig enkelt siden denne funksjonaliteten medfølger i Linux uten å ty til hacks. Etterpå analyserte jeg dataene grafisk i Wireshark på en Windows 7-maskin.

Her så jeg følgende:
Per sekund gikk det 4000 pakker på USB-grensesnittet.

Flyten er todelt og er som følger (hver vei i hver av flytene har ~1000 URBs per sekund):
-Host sender en URB_SUBMIT til lydkort via Isochronous OUT (544 bytes, 8 ISO descriptors)
-Lydkort responderer til Host med URB_COMPLETE via Isochronous IN (84 bytes, 1 ISO descriptor)

-Host sender en URB_SUBMIT til lydkort via Isochronous IN (80 bytes, 1 ISO descriptor)
-Lydkort responderer til Host med URB_COMPLETE via Isochronous OUT (192 bytes, 8 ISO descriptors)

Jeg ser vanligvis 2000 interrupts per/sec i mitt system. Det spørs om dette er URB_SUBMIT URBene som hosten genererer.

Siden det er kun URBs som sendes på grensesnittet ved avspilling hadde jeg forventet at NRPACKS hadde hatt direkte virkning på dette, siden NRPACKS per definisjon kontrollerer hvor mange pakker som går inn i hver URB.

Uansett om NRPACKS er 1 eller 20 går det akkurat like mange URBs ut på USB-grensesnittet og hver URB er akkurat like stor som før (length på hver URB). NRPACKS har derfor ingen som helst virkning på USB-dataene som går til og fra lydkortet på mitt system. Av ren nysgjerrighet må jeg si at jeg blir mer og mer spent på hvordan dette egentlig henger sammen.

Lite utdrag fra capture-filen etter at den er åpnet i Wireshark, sånn for morro skyld (3.1 er lydkortet):

 

[marsboer]

Ble en merkelig dobbelpost når jeg redigerte.. slettet...

 

[marsboer]

Fra side 269 i USB 2.0 spesifikasjonen, kap 9.6.6:

Each endpoint used for an interface has its own descriptor. This descriptor contains the information
required by the host to determine the bandwidth requirements of each endpoint.

Hvis jeg ser på mitt lydkorts descriptorer for Asynchronous Isochrounous overføring får jeg følgende to "treff". Fra usbmon-dumpen ser jeg at bEndpointAddress 0x01 er involvert i den ene av de to transaksjonene

root@hifi:~# lsusb -v -s 004:003| grep -C 6 Asynch
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               1
--
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               1

I tillegg ser jeg i dumpen at også Endpoint 0x81 er involvert. Her er hva som dukker opp på denne:

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes           17
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Feedback
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval               4
--
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes           17
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Feedback
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval               4

Fra side 271 i USB 2.0 spesifikasjonen om "bInterval"

Interval for polling endpoint for data transfers.
Expressed in frames or microframes depending on the
device operating speed (i.e., either 1 millisecond or
125 μs units).
For full-/high-speed isochronous endpoints, this value
must be in the range from 1 to 16. The bInterval value
is used as the exponent for a 2^(bInterval-1) value; e.g., a
bInterval of 4 means a period of 8 (24-1).

Siden wMaxPacketSize er 1024 må det være snakk om en High Speed enhet, siden dette ikke støttes av Full Speed. Måleenheten blir da 125us. Med andre ord vil regnestykket være som følgende med annonsert bInterval på henholdsvis 1 og 4 for async og feedback:
Async: 2^(bInterval-1) = 2^(1-1) = 1 x 125 us
feedback: 2^(bInterval-1) = 2^(4-1) = 8 x 125 us = 1 ms

Hvis vi ser på endpoint adressen til lydkortet og setter overføringene i sammenheng med dette får jeg følgende dataflyter:

-Endpoint 0x01 (async): Host sender en URB_SUBMIT til lydkort via Isochronous OUT (544 bytes, 8 ISO descriptors)
-Endpoint 0x81 (feedback): Lydkort responderer til Host med URB_COMPLETE via Isochronous IN (84 bytes, 1 ISO descriptor)

-Endpoint 0x81 (feedback): Host sender en URB_SUBMIT til lydkort via Isochronous IN (80 bytes, 1 ISO descriptor)
-Endpoint 0x01 (async): Lydkort responderer til Host med URB_COMPLETE via Isochronous OUT (192 bytes, 8 ISO descriptors)

Variasjon med datarater:
Hvis vi drar regnestykket fra denne lettleste og ferske artikkelen fra en eller annen XMOS guru: Henk Muller, Principal Technologist XMOS Ltd. - June 27, 2012: Fundamentals of USB Audio | EDN

kommer vi frem til regnestykket nedenfor, med visshet om at hw_params viser S32_LE uansett 16 eller 24 bit ved avspilling i mitt system. 32 bit er det samme som 4 byte

For 44.1kHz avspilling gjelder da følgende:
44100 x 2 channels x 4 bytes = 352800 bytes/sec = 352,8 bytes per 1 ms siden det går ~1000 URBs per sekund med denne trafikken i følge USB-dumpen.
Dette passer heldigvis veldig bra med URB_SUBMIT fra host til lydkort via Isochronous OUT på 544 byte. Hvis man studerer header feltene i URBen i Wireshark ser man at URB length i denne URBen er 352 bytes. Med andre ord en perfekt match.

Ved å bytte til 24bit 192kHz forblir alle URBene identiske i størrelse i usbmon capturen med unntak av ovenfornevnte URB, som nå har en total lengde på 1728 byte og en URB length på 1536.
192000 x 2 channels x 4 bytes = 1536 bytes
Nok en perfekt match. Antallet URBs utsendt er det samme som ved lavere bitrater.

Jeg blir fremdeles ikke noe klokere på interruptdelen, men det er i hvertfall 2 stk isokrone IN feedback channels, en i hver retning, med et intervall på 1 ms = 1000, så dette passer jo veldig bra med at jeg ser 2000 int/sek. Men jeg har ikke på noen måte fått det bekreftet at det er disse som fremkaller de gjeldende interrupts. Ikke en gang om det er relevant for saken.

Uansett er det nyttig med kjøtt på beinet for videre analyse, om ikke annet enn for å kunne stille relevante og konkrete spørsmål til utviklerne om jeg blir stående fast i min nysgjerrighet for å finne ut hvordan dette faktisk fungerer.

 

[marsboer]

Hmm, når jeg tenker meg om er det jo veldig logisk at kommunikasjonen skjer etter feedback endpointets intervall siden det trossalt er et 1:1 avhengighetsforhold i trafikken mellom async og feedback i usbmon dataene. Det hjelper ikke om async opererer på 125us når neste URB uansett ikke sendes før feedback er mottatt på den forrige.

 

[nma]

Min: (Ayre QB-9)

Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               1
        AudioControl Endpoint Descriptor:
          bLength                 8
          bDescriptorType        37
--
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               1
        AudioControl Endpoint Descriptor:
          bLength                 8
          bDescriptorType        37

 

[nma]

Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes           17
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Feedback
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval               8

Endpoint Descriptor:

        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes           17
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Feedback
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval               8

 

[marsboer]

Hva slags interrupt per sec får du med "procinfo -d -n 1"?
Varierer denne med bitrate og nrpacks?
I såfall er det sikkert snakk om en helt annen implementasjon.

bInterval på 8 blir jo 2^(8-1) = 2^7 = 128 x 125us = 16 ms
Hvis din Ayre fungerer på samme måte som min M2Tech skulle det da blir 1000 / 16 = 62,5 int/sec.

Dette høres veldig lite ut, så det hadde jo vært morsomt å vite hva som egentlig går på USB-porten. Det vil si om implementasjonen ligner i det hele tatt eller om det er to helt forskjellige virkemåter.

Jeg la ut en liten veilledning for hvordan du kan sniffe USB-data i linux her: Hi-Fi Debian MPD USB transport - marsboer.net wiki

 

[Oblivion]

Med endel USB 2.0 Audio adaptere blir det i utgangspunktet 2000 interrupts pr. sekund.
Min erfaring er at det med disse er mulig å få interrupts ned i ca. 1400 pr. sekund ved å kompilere en kernel med NRPACKS=32 til 64, og MAX_PACKS=128 til 256 (#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */) - 128 gir da 1024 som er det maksimale som blir brukt, men det er sjekk på MAX_PACKS_HS verdien i koden og er den høyere enn 1024 blir det kun brukt 1024.

Jeg regner med at 1000 av de i utgangspunktet 2000 interrupts er IN-transfers fordi USB 2.0 Audio adapteret har enablet en inngående lydkanal (som ikke brukes) og når en øker NRPACKS og MAX_PACKS så er det den utgående OUT-transfers som kan reduseres ned til (inklusive kontroll / feedback) ca. 400 interrupts - 1000 for IN pluss 400 for OUT = 1400.

Som det er beskrevet i artikklen til Henrik Muller så er ikke feedback fra USB 2.0 Audio adapteret nødt til å fungere 1:1, men med noen millisekunders mellomrom...

In order to ensure that the host sends the right amount of data, and not too much or too little, the host requests the current sample rate over an interrupt endpoint. Every few milliseconds the average sample rate over the last period is reported back as a 16.16 bit fixed point number. If the last period averaged out as 12.001 frames, then the value 0x000C0041 will be reported (65536 * 12.001).

På de USB 2.0 Audio adapterne jeg har så varierer dette "feedback" tidsintervallet mye fra enhet til enhet og det har også med hvor mye som buffres og hvor mye "inteligens" USB 2.0 Audio adapteret har for å kontrollere dette.

På de USB 2.0 Audio adapterne hvor jeg får rundt 1000 interrupts pr. sekund som det dårligste / høyeste så er det IKKE definert noen IN enhet og derfor blir 1000 interrupts pr. sekund borte / ikke generert i utgangspunktet.

Med NRPACKS=1 greier jeg å få til å generere 1222 interrupts pr. sekund med mitt ObliUSB kort, men med NRPACKS=32 og MAX_PACKS=256 så går dette ned til ca. 140 interrupts pr. sekund. Av de 1222 interrupts så regner jeg med at det er 1000 interrupts på OUT-transfers og at kontroll / feedback er økt fra de 126 som er standard til 222 fordi buffer strukturen får problemer i USB adapteret og må øke feedback for å prøve å få timingen korrigert / optimalisert.
Av disse ca. 140 interrupts er det 126 interrupts som skyldes USB 2.0 Audio adapteret / feedback og bare ca. 15 interrupts pr. sekund som skyldes data som blir sendt til USB adapteret.
Skal prøve å få redusert disse 126 interrupts ned til under 40 og hvis mulig ned mot 20.

There are four sorts of IN and OUT-transfers in USB: Bulk, Isochronous, Interrupt, and Controltransfers.

Hvis det ikke er mulig å få de USB adapterne dere bruker til å generere under 1000/2000 interrupts pr. sekund selv med NRPACKS= 32 til 64 og MAX_PACKS=128 til 256 så ville jeg ha sjekket hvilken OUT-transfer type som er i bruk, og / eller om det er en konstant kontroll / feedback fra USB adapteret som forårsaker interruptene.

 

[nma]

jeg får 1002 interrupts med nrpacks1.

 

[marsboer]

Det står faktisk i usbmon dataene at det er isokron IN og OUT som er i bruk. Dette er også det korrekte for audio-bruk, men f.eks M2Tech har tidligere brukt en modifisert ikke-standard variant av bulk tidligere i følge deres egne hjemmesider. Problemet med dette var at det krevde egne drivere, og de har gått bort fra denne tilnærmingen med HiFace Two.

Siden Isokron overføring i utgangspunktet baserer seg på garantert tildeling av båndbredde og utsending av data ved faste intervaller vil jeg egentlig anta at det er adapterene som viser type 1000 int/sek som følger standarden for isokron asynkron overføring til punkt og prikke, mens det er de som har vesentlig lavere enn dette som bruker modifiserte varianter.

Det er nok slik at feedback ikke trengs for hver URB, men i mitt system og implementasjonen til M2Tech HiFace Two er det helt klart et 1:1 forhold som ikke virker å variere i det hele tatt.

Et par spørsmål:
Benytter ObliUSB seg av asynkron isokron overføring?
Har du sett på dataene i usbmon enda? Det hadde vært interessant siden dette grensesnittet utviser en helt annerledes oppførsel enn de "ordinære" async USB 2.0 adapterene.

 

[Oblivion]

Et par spørsmål:
Benytter ObliUSB seg av asynkron isokron overføring?
Har du sett på dataene i usbmon enda? Det hadde vært interessant siden dette grensesnittet utviser en helt annerledes oppførsel enn de "ordinære" async USB 2.0 adapterene.

Isochronous asynchronous.

Har ikke noen windows maskin for å se på data, men jeg kan sende en usb-capture.out fil til deg ??
Kan jeg i tilfelle spille fire filer med forskjellige samplerater (skifter med noen sekunders mellomrom) mens tcdump samler data?
Eller må jeg lage fire forskjellige usb-capture.out filer - en for hver samplerate ??

EDIT:
root@rARM:~# modprobe usbmon
FATAL: Module usbmon not found.

Det betyr vel at jeg i tilfelle må kompilere en ny kernel med usbmon...
Min kernel er renset for stort sett alt som ikke må være der for å kunne spille musikk med MPD...

 

[Oblivion]

Mitt USB adapter genererer 126 interrupts i sekundet på "tomgang" når MPD har satt igang spilling og koblet til adapteret, men jeg fremtvinger en feil slik at MPD ikke sender data.
WaveIO adapteret generer under de samme forhold 1014 interrupts.

Har prøvd å analysere de funn som tilsammen er gjort og har brukt kalkulatoren på mobilen..
Hvis det er en form for avrundings feil slik at 126 egentlig er 125 og 1014 egentlig er 1000 så har jeg en teori som jeg skal få sjekket ut.
På mitt kort er det satt 16ms som sjekk / feedback intervall fra adapteret og det skulle generere 62.5 interrupt pr. sekund, og hvis da USB / ALSA genererer et interrupt for hver interrupt adapteret genererer så blir det 125 interrupt i sekundet.

Hvis de andre USB adapterne har satt sjekk / feedback intervallet til 2ms og den over nevnte "teori" stemmer så skal det bli generert 1000 interrupt pr. sekund på "tomgang".

Da er kanskje "tomgangs" interruptene som nå er 125 og 1000 kanskje forklarte.

Hvis mitt adapter brukes med NRPACKS=1 så genereres det ca. 1000 ekstra interrupts pr. sekund - det blir ca. 100 interrupt mer enn de 1000 slik at det nærmer seg 1222, men det kan være logisk fordi adapteret ser at det i dette tilfellet blir ustabil timing / avvik og øker feedback raten..
I alle tilfelle så går antall interrupt pr. sekund ned når NRPACKS økes til minimum 16 og MAX_PACKS økes fra 20 og opp til 128 (har ikke fin sjekket nøyaktig breakpoint).
Da (NRPACKS=16 til 32) går interrupt raten ned til ca. 140 (139 - 143 litt avhengig hva som spilles og hva forskjellige parametre er satt til).

Sånn cirka 16 interrupts pr. sekund brukes da til selve "avspilling"...
Selve data overføringen bør skje med DMA og interruptene bør ikke komme fra selve data overførings rutinene, men er vel interrupt fra kontroll / feedback rutiner for å holde timingen i sjakk.
Jeg har observert at det også her blir forskjeller med forskjellige samplerater, bitdybder og hva USB adapteret har som device (32bit, 24bit eller 16bit).

Når firmwaren nå får seg en overhaling og en får sjekket med høyere feedback / sync intervaller enn 16ms og at adapteret også fungerer som 16bit og 24bit "device" så bør det ikke bli mange interrupt igjen pr. sekund....

For de adaptere som har 1000 interrupt pr. sekund på "tomgang" så genereres det slik jeg forstår 1000 nye interrupt pr. sekund når det spilles. For WaveIO adapteret går dette ned til ca. 400 (pluss 1000 "tomgang" = 1400) når NRPACKS og MAX_PACKS økes vesentlig.

Hvis dette ikke skjer på endel adaptere så må det skyldes forskjeller i settinger i selve adapterene fordi jeg har modifisert stort sett alle parametre i USB og ALSA sourcekoden og også forandret (flyttet) slik at SPEED_FAST og SPEED_HIGH kjørte den samme koden slik at om noe ble identifisert feil så ville "riktig" kondisjonal kode bli brukt, men det ble ingen forbedringer av dette.

Med en maksimal kø lengde for URB på 24ms så skal det bli interresant å se hva som skjer når jeg i USB adapteret øker de 16ms sjekk / feedback til 32ms og høyere - kanskje må maksimal kø lengde for URB økes og eventuellt antall URB økes (standard 8).
Jeg har allerede testet med 32ms kø lengde for URB og med 16 URB Uten at jeg merket noen negative tendenser, men gikk tilbake igjen da jeg heller ikke fikk noen positive tendenser.

 

[Oblivion]

Da burde de være rimelig klart at NRPACKS IKKE betyr 1ms pr. NRPACKS i forhold til IRQ.
Og også like klart at NRPACKS er det antallet packs som en URB består av.

Jeg er fortsatt like overbevist om at dette stemmer og det er ikke fordi som det har blitt påstått:

Da burde de være rimelig klart at NRPACKS IKKE betyr 1ms pr. NRPACKS i forhold til IRQ.
Og også like klart at NRPACKS er det antallet packs som en URB består av.

Hæh? Dette er jo akkurat det motsatte? Gjør du deg vanskelig med vilje?


NRPACKS = antall full frames per URB = antall ms intervall mellom URBs. Det er EKSAKT dette det står i kildekoden.
Antall packs varierer mellom USB 1.1 og USB 2.0/3.0 (8 ganger høyere) per URB uten at NRPACKS gjør det.

@oblivion:

Jeg mener selv at jeg har vært meget overbærende ovenfor dine bastante utspill og den kunstig høye selvtilliten uten noen form for virkelighetskontakt du i større og større grad har utvist utover i denne tråden. Dette er fordi jeg hele tiden har tenkt at dette er komplekst og siden Linux, ARM-platforme, kompilering osv virker å være nytt for deg så kan alle selvsagt gå i den fella å tro at verden er så enkel den fremstår ved første øyekast, spesielt når man har teknisk bakgrunn.

Jeg mener selv at jeg gang på gang har prøvd å ta dine bastante utspill og prøvd å forklare hvorfor disse har vært ukorrekte/unøyaktige med henvisninger til nøytral dokumentasjon. Jeg har prøvd å forholde meg saklig hele veien. Dette gjelder alt i fra påstanden om feil tolkning av CPU affinity og Irix mode i top, kernel timers, NRPACKS, packs, microframes, 0.125 vs 1ms og sikkert enda noen ting.

At du etter de siste sidene klarer å konkludere med dette:

Jeg har lurt en stund på om du bare ikke vill innrømme at NRPACKS => NR (number (of)) PACKS som er det antallet PACKS en URB består av. Det essensielle har også vært at du har påstått at NRPACKS er det antall ms som står i forhold til interrupts.


Ingen av disse påstandene har vært korrekte.


Og du har selv dokumentert at NRPACKS ikke gjør det du har påstått.

er så drøyt at jeg faktisk herved kommer til å endre min innstilling fra å forsøke å hjelpe deg etter beste evne med alt i fra dokumentasjon, wiki og annen hjelp, til "do not feed the troll". Helt seriøst.

Det er du som er ute på dypt farvann, Oblivion. Hvis du hadde orket å google denne variabelen så ville du sett at dette er ganske ny kode som stammer fra januar 2012,

 

[marsboer]

Jeg kan virkelig ikke fatte hvordan du fremdeles ikke har tatt innover deg det faktum at all overføring i USB-standarden dreier seg om knytningen mot 1ms eller 125us frames, uansett datamengde og interruptrates. Dette fremkommer hvorenn du snur deg i USB 2.0 dokumentasjonen eller i kildekoden.

Hvorfor du drar IRQ inn i NRPACKS-diskusjonen vet jeg ikke, siden NRPACKS i følge beskrivelsen må forstås som antall packs per URB, eller for å være helt korrekt om man tar høyde for 8 x kompensasjonen for 125us pakkene i kildekoden, antall 1 ms USB-frames per URB, som igjen kan representere en vilkårlig mengde data basert på hvor mye som puttes inn i hver microframe.

En eventuell påvirkning på IRQ-frekvens er i såfall en indirekte konsekvens av URB-frekvens, ikke en konsekvens av NRPACKS direkte.

Hvordan kan du forsvare et synspunkt hvor du hardnakket påstår at NRPACKS regulerer antall pakker per URB (som både du, jeg og beskrivelsene i dokumentasjonen er enige om, gitt korrekt forståelse av "pakker" ved high speed+!) uten å samtidig ta inn over deg at dette, som en direkte konsekvens av at en en USB-pakke representeres som en variabel datamengde i en fast tidsluke ved bruk av isokron USB, også medfører at tidsintervallet for utsending av URB også reguleres?

 

[Oblivion]

Jeg kan virkelig ikke fatte hvordan du fremdeles ikke har tatt innover deg det faktum at all overføring i USB-standarden dreier seg om knytningen mot 1ms eller 125us frames, uansett datamengde og interruptrates. Dette fremkommer hvorenn du snur deg i USB 2.0 dokumentasjonen eller i kildekoden.

Hvorfor du drar IRQ inn i NRPACKS-diskusjonen vet jeg ikke, siden NRPACKS i følge beskrivelsen må forstås som antall packs per URB, eller for å være helt korrekt om man tar høyde for 8 x kompensasjonen for 125us pakkene i kildekoden, antall 1 ms USB-frames per URB.

En eventuell påvirkning på IRQ-frekvens er i såfall en indirekte konsekvens av URB-frekvens, ikke en konsekvens av NRPACKS direkte.

Hvordan kan du forsvare et synspunkt hvor du hardnakket påstår at NRPACKS regulerer antall pakker per URB (som både du, jeg og beskrivelsene i dokumentasjonen er enige om, gitt korrekt forståelse av "pakker" ved high speed+!) uten å samtidig ta inn over deg at dette som en direkte konsekvens av at en en USB-pakke representeres som en variabel datamengde i en fast tidsluke ved bruk av isokron USB også medfører at tidsintervallet for utsending av URB også reguleres?

Du burde slutte å våse videre og innrømme at når du hevdet at NRPACKS var en setting som regulerte noe i 1ms step så var dette feil.
Det korrekte er jo at NRPACKS er en setting som angir hvor mange (mange = NR = antall) PACKS det er i en URB.

Du tok feil og det burde du ganske enkelt innrømme.

Jeg konstanterer i allefall at du tok feil og at det i ettertid har vært mange forsøk på å bortforklare dette og at du har som jeg "quotet" i mitt forrige innlegg også prøvd deg på dårlig hersketeknikk uten at det har kunnet rokke ved fakta.

 

[marsboer]

Du burde slutte å våse videre og innrømme at når du hevdet at NRPACKS var en setting som regulerte noe i 1ms step så var dette feil.
Det korrekte er jo at NRPACKS er en setting som angir hvor mange (mange = NR = antall) PACKS det er i en URB.

Noen spørsmål til deg.

Er du enig i at en full frame har en varighet på 1 ms?
Er du enig i at en microframe har en varighet på 125 us?
Er du enig i at en pakke (pack) er enten en microframe eller frame med data?
Er du enig i at det i kildekoden kompenseres med en faktor på 8 for "packs_per_ms" på High Speed+ og at dette tallet i etterkant ganges med NRPACKS gitt at denne er innenfor gyldig område?
Er du enig i at NRPACKS regulerer antall pakker som skal inn i en URB?

Eller for å si språklig helt enkelt hvordan det fungerer i kildekoden:

Full Speed USB (altså USB 1.1):
packs_per_ms blir satt til 1
urb_packs settes deretter lik nrpacks gitt at nrpacks er innenfor spesifiserte max og min verdier, dvs 8 i dette eksempelet
deretter settes urb_packs = urb_packs * packs_per_ms, noe som vil si at urb_packs = 8 * 1 = 8 pakker á 1 ms = 8 ms

Samme eksempel, men denne gangen med High Speed/Super Speed (USB 2.0/3.0):
packs_per_ms blir nå satt til 8
urb_packs settes deretter lik nrpacks gitt at nrpacks er innenfor spesifiserte max og min verdier, dvs 8 i dette eksempelet
deretter settes urb_packs = urb_packs * packs_per_ms, noe som vil si at urb_packs = 8 * 8 = 64 pakker, men denne gangen á 125 us fordi det er snakk om high speed. 64 * 125 us = 8 ms

NRPACKS er egentlig bare et tall hvis eneste funksjon er å være en faktor for antall pakker per URB, som egentlig mistet sin konkrete forståelse etter at 125 us pakker ble innført. I begge tilfeller er NRPACKS 8, og dette reflekterte også det reelle antallet pakker per URB i USB 1.1. I USB 2.0 med samme NRPACKS-verdi på 8 er det reelle antallet internt 64 pakker per URB, og det er dette tallet som lagres i urb_packs.

Men om man i stedet for å fokusere på antall, fokuserer på tidsintervallene disse pakkene trenger, så vil du ende opp med det samme tallet i ms for begge uansett USB-hastighet. Ergo er dette en mer korrekt tolkning av NRPACKS som også gjelder for USB 2.0, mens det å tolke det bokstavelig som antall pakker per URB med 125 us pakker faktisk blir direkte feil med en faktor på 8!

 

[Ludo]

Har ikke lest hele tråden, men har et kort spm:

MPD kjører man på en egen PC, og dette må jo ha et eget lydkort. Vet dere om exaDevicies USB-> I2S funker på denne? Kan denne confes i ALSA?
Har en helt passiv kjølt i5 3,3 GHz m/8GB RAM og 120GB SSD - skulle vel egentlig være overkill på en slik jobb? Kan man få full funksjonalitet med Intel Atom?

 

[marsboer]

Så vidt jeg kan se etter et kjapt google-søk så er dette kortet avhengig av 3. parts-drivere. Det virker ikke som om det er utviklet drivere for Linux, selv om temaet har vært brakt på banen flere ganger. Med andre ord fungerer nok ikke dette så bra. For å teste kan du jo f.eks prøve en ubuntu live CD eller tilsvarende og se om lydkortet detekteres og om du kan avspille lyd. Da slipper du i hvertfall å reinstallere maskinen.

En Atom-maskin vil ikke ha noen problemer med å dra MPD, gitt at du ikke har tenkt å kjøre noen form for etterprosessering i form av korreksjonsfiltre eller høykvalitets resampling. Jeg regner med at dette også gjelder for ren avspilling av 32bit 384kHz.

Min personlige mening er imidlertid at Atom ikke har noe som helst i en datamaskin å gjøre, men la ikke dette være styrende for ditt valg

 

[Ludo]

Min personlige mening er imidlertid at Atom ikke har noe som helst i en datamaskin å gjøre, men la ikke dette være styrende for ditt valg

Du skulle bare visst hvor enige vi er på dette området! Skal teste med en live-CD, et godt tips - tusen takk!

 

[Ludo]

Et relevant spm til: blir lydkvaliteten endret (bedre/dårligere) dersom man spiller av musikken via MPD eller er det kun et GUI som blir 'flottere'? Gitt at enhetan man spiller av med støttes selvsagt..!

 

[Oblivion]

Vet dere om exaDevicies USB-> I2S funker på denne?

Ingen av exaSound enhetene fungerer med Linux.
De er ikke USB 2.0 Audio kompatible, og trenger egne block mode drivere.
Om drivere for Linux blir laget er uvisst, men George har hatt mange henvendelser ang. dette.

 

[Ludo]

Takk for svar Oblivion Da blir det fortsatt Foobar2K og ASIO-driverne til exa som blir veien å gå her i heimen

 

[Goophy]

Min personlige mening er imidlertid at Atom ikke har noe som helst i en datamaskin å gjøre, men la ikke dette være styrende for ditt valg

Får man lov til å spørre om hvorfor?
Har brukt Atom til mpd og nå til xbmc uten noen som helst problemer.

Tenker du på Intel sine brikkesett som normalt sett følger Atom?

 

[Ludo]

Hmmm, sikkert fordi Atom ofte oppleves som altfor tregt - det er ihvertfall min erfaring etter å ha brukt en Zotac Zbox i ett år.... selv med 4GB RAM og SSD blir det suppetregt innimellom... Men en god tanke ihvertfall da!

 

[marsboer]

Et relevant spm til: blir lydkvaliteten endret (bedre/dårligere) dersom man spiller av musikken via MPD eller er det kun et GUI som blir 'flottere'? Gitt at enhetan man spiller av med støttes selvsagt..!

Om lydkvaliteten blir bedre eller dårligere kommer selvsagt an på hva man sammenligner mot og hvilken konfigurasjon man kjører. Det er imidlertid ikke spesielt kontroversielt å hevde at man med en lettvekts Linux distro og en enkel daemon som avspiller i det minste har større forutsetninger for å tilrettelegge systemet i detalj for optimal avspilling enn med en GUI-låst avspiller på f.eks Windows og OS X.

Min subjektive erfaring er at en fornuftig oppsatt Linux-maskin med MPD låter bedre enn alle andre PC baserte løsninger jeg hittil har prøvd. Om MPD i det hele tatt er relevant for resultatet, eller om andre avspillere også kunne gjort det samme på den samme Linux-installasjonen er imidlertid uvisst.

Den største objektive fordelen med MPD slik jeg ser det, er at den er tilrettelagt for klientbasert styring og at man får en stabil avspillerløsning som drar det meste og som på grunn av sin åpne natur kun vil bli bedre og bedre uten risiko for å bli avskaffet ved neste budsjettkutt (ref Logitech og SqueezeBox)

 

[Ludo]

Men må nesten vente på støtte for exa I2U før jeg fortsetter med en slik løsning... takk for info ihvertfall!

 

[ivarlo]

Da har også jeg fått testet Man made Voyage MPD/mPad som styringssystem for digital avspilling i heimen.
Kort fortalt banker den all annen avspilling jeg har prøvd under osx, det være seg avspilling i os og vha avspillere som itunes, Decibel, Pure vinyl og Amarra.

Klarere, renere, mer detaljer, bedre rom, bedre mikro og makro-dynamikk er stikkord som passer for MPD.

Litt praktiske og tekniske problemer til tross... Denne blir!

 

[gut_man]

Da har også jeg fått testet Man made Voyage MPD/mPad som styringssystem for digital avspilling i heimen.
Kort fortalt banker den all annen avspilling jeg har prøvd under osx, det være seg avspilling i os og vha avspillere som itunes, Decibel, Pure vinyl og Amarra.

Klarere, renere, mer detaljer, bedre rom, bedre mikro og makro-dymnamikk er stikkord som passer for MPD.

Litt praktiske og tekniske problemer til tross... Denne blir!

Hyggelig at flere bekrefter hva jeg også har hørt! Enda hyggeligere at det kommer fra en med de analoge referanserammene i orden. Velkommen i fanklubben ivarlo!

 

[ivarlo]

Takker. En stor takk også til Man for imaget og støtte underveis med å få systemet opp og gå

 

[nma]

Bare hyggelig! Btw, hvis du har en macmini 09 modell, så kan jeg erindre at det er den nest ytterste USB-porten som er den ideelle å bruke. Om det har noe å si i praksis, vet jeg ikke.

 

[Nido]

Jeg får slenge meg på både lydbeskrivelse og takk til Man! Et spm til Man, vil imaget fungere med intel nuc?

 

[nma]

Jepp.

 

[Ludo]

Hvilken USB -> SPDIF funker bra med denne? Har en HiFace M2Tech sak liggende, tror det er første utgaven - den synes jeg var litt tam under Windows...

 

[Oblivion]

Hvilken USB -> SPDIF funker bra med denne? Har en HiFace M2Tech sak liggende, tror det er første utgaven - den synes jeg var litt tam under Windows...

Har også en HiFase liggende...

Hvis exaU2I hadde fungert med Linux ville det ha vært noe av det mest optimale som kan kjøpes tror jeg.

Jeg holder på med et USB adapter som får "tripple" isolering og som programmerer ES9018 DACer optimalt via I2C.
Ved samplerate skifte, mute, bytte mellom PCM / DSD etc. kan en velge hvordan DAC skal programmeres ved hjelp av et script som en programmerer USB adapteret med...
Også volumkontroll kan styres fra app / iPad / MpOD / MpAD.
Også SPDIF i ES9018 kan spilles av fra en inngang via kontroll fra USB adapteret.

Det ser også ut til at oppsettet blir slik at USB adapteret vil bli sett som to ALSA lydkort av Linux.
Et 32bit ALSA lydkort for (16bit) 24, 32bit og DSD avspilling og et 16bit ALSA lydkort for optimal avspilling av 16bit (det som de fleste har 99% av).
Med MpOD / MpAD velger en da i menyen hvilket av disse to "lydkortene" en vil spille via.
Foreløpig blir dette et manuellt oppsett, men 32bit varianten spiller ALLE formater.
Jobber med at 16bit automatisk spiller via det ene logiske adapteret og resten via det andre.

Forskjellen dette 16bit adapteret gir i praksis er at kun 1/2 parten av data mengden blir prossesert av MPD og det blir ingen unødvendige konverteringer fra 16bit til 24 eller 32bit i forkant.
For USB bus og USB adapter oppnås en forbedring med en faktor på opp til 16 ganger fordi en kan optimere USB adapteret (det er USB adapteret som bestemmer feedback variant / timing og har den overordnede kontrollen på data overføringen) og FIFO i USB adapteret har 16 ganger så lang "spille" / buffer tid i forhold til 32bit adapteret som må forholde seg til DSD og opp til 384k/32bit dataoverføring.

Ser ikke helt bort ifra at dette USB adapteret kan bli tilgjengelig - Det fungerer med nyere Linux, OSX 10.6.4 -> og Windows XP -> Windows 8 64bit (også ASIO drivere, og det jobbes med DSD256 støtte)...

 

[marsboer]

Hvilken USB -> SPDIF funker bra med denne? Har en HiFace M2Tech sak liggende, tror det er første utgaven - den synes jeg var litt tam under Windows...

1. generasjon M2Tech er ikke optimal til dette formålet. Den benytter seg ikke av standarddriveren slik HiFace Two gjør. Så vidt jeg kan se på hjemmesidene finnes ingen driver for Linux i det hele tatt. Men om du vil komme i gang å teste løsningen er HiFace Two velegnet både lydmessig og drivermessig for en rimelig penge.

 

[gut_man]

Lydmessig er det imo ingenting å utsette på M2tech hiface two. Det går sikkert an å ta det lenger enn et hiface two, men dette er relativt upløyd mark så hvor man evt bør sette inn kronasjen for å tyne maks ut av MPD spilleren er ganske uvisst. Det som er sikkert er at m2tech adapteret ikke gjør skam på seg. I mitt anlegg har MPD-m2tech feid alle windows baserte avspillere via Lynx AES 16e av banen, som igjen i sin tid feide et blodtrimmet BASE drivverk av banen.. Kommer sikkert til å teste ut noe annet etterhvert, men dette funker brillefint enn så lenge!

 

[Ludo]

Hvor kjøper man HiFace Two?