Voyage MPD

[marsboer]

Så var det et lite "breakthrough" på USB og CPU-bruk (jeg bruker Debian standard 3.2.0-3 rt-kernel, men dette gjelder for nye kernels også)
I motsetning til Oblivion er ikke jeg av den oppfatning at det er noe poeng å få all CPU bruk så lav som overhodet mulig. Jeg tror heller ikke at kernelutviklerne for en så viktig driver som ehci_hcd/xhci_hcd er en haug med rablende fylliker som inkluderer en masse kode på uintelligente måter som sluker CPU cycles for morro skyld.
Bekreftelsen på dette er vel egentlig at xhci_hcd (USB 3.0) som jo er en ny driver er akkurat like "ille" som ehci_hcd (USB 2.0).

MEN, Oblivion har likevel et godt poeng når han klager på CPU-bruken på Intel platformen kontra f.eks ARM. Det gir ingen mening for meg at dette skal variere så fryktelig, vel og merke gitt at det er samme source code som ligger til grunn for drivermodulene.

Den gode nyheten er imidlertid at jeg har funnet ut hva som er den store synderen. På mitt system aktiveres det av en eller annen grunn to tråder for USB 2.0 hubens IRQ 23, sånn bare til info når du ser på outputen. I tillegg er det verdt å merke seg at "top" kjører med "Irix mode ON" som default, noe som vil si at prosentvis CPU bruk oppgitt for en prosess er i forhold til den CPU-kjernen den kjører på, ikke i forhold til all CPU-kapasitet på systemet. 4% CPU for en prosess i "top" med "Irix mode on" vil dermed si 1% CPU bruk om man ser på alle CPUer totalt i et quad system. Man kan toggle Irix-mode med "I" i top. Alle skjermdumpene er med standardinnstillinger i top, med unntak av at jeg viser alle kjernene øverst.

OK. Dette var utgangspunktet:

Deretter kom jeg hit:

For til slutt å havne her:

Dette krevde ingen hacks, source kode endringer, nrpacks, eller kompilering. Synderen er rett og slett SMP og veksling mellom ulike CPUer!
Mitt system har en dual core i3 med hyper threading, dvs 4 logiske kjerner. I det øverste bildet flyter IRQ-trådene fritt mellom CPUene (default). MPD er låst med CPU affinity til CPU 2.

I neste bilde har jeg satt CPU affinity til 3 (altså en annen enn MPD) for IRQ-trådene til USB huben. Allerede her ser vi en fin nedgang i CPU bruk.

I siste bilde har jeg satt samme affinity som MPD. Det vil si at MPD og IRQ-prosessene befinner seg på samme CPU. Her får vi en CPU-bruk som ser langt mer "riktig" ut for IRQ-trådene. Her vil CPU-cachen treffes så ofte som overhodet mulig siden mpd og interrupts befinner seg på samme CPU.

Ideen til å teste dette kom ikke på måfå selvsagt. Man kan vrenge mange prosent (faktisk flere titalls er rapportert) ekstra ytelse fra servere med høyhastighetsnettilkoblinger som f.eks 10GB ved å tilordne interrupt-tråder for nettverkskortet til CPUene på intelligent vis sett i forhold til NUMA og applikasjoner.
Dette forklarer også hvorfor et system uten mange kjerner ser vesentlig lavere CPU-bruk på USB out-of-the-box.

Jeg har vurdert å dytte nettverkskortets IRQ inn på samme CPU, men jeg er fremdeles av den oppfatning av at nettverkskortet bare kan flyte rundt som før og at trafikken ikke bør prioriteres høyere enn noe annet. Rett og slett for å gi mest mulig CPU-tid til den tidskritiske delen av avspillingen.

Scriptet mitt er oppdatert for å ta høyde for dette, samt å gjøre det litt lettere å teste affinity (enkelt å resette til default). Forøvrig er det rt-kernel og nrpacks=1 som har kjørt på systemet med suksess etter at jeg kastet ut Samsung 9-laptopen og satte opp mpd-boksen skikkelig med picopsu og passiv kjølt kabinett i massiv aluminium i stedet. Laptopen passet bare ikke til formålet på grunn av alt dillet og tullet det fokuseres på i en typisk laptop.

Scriptet: http://www.marsboer.net/shared/hifi-linux/hifi.sh

 

[Oblivion]

Med nytt script og Iris mode for top så ble CPU forbruket rapportert mer forståelig.

Med 3.2.0-3-rt-amd64 SMP PREEMPT RT så er CPU forbruk for MPD på 0.1% og USB IRQ 0.9%.

Med ARM med 3.5.2 PREEMPT så er CPU bruk for MPD 0.3% og med 800MHz så stemmer det bra med i5 på 0.1% @ 2.5GHz.
Men fortsatt lite av CPU forbruk på annet enn nettverks IRQ.

Som en referanse så skal jeg sjekke top på en Mac når en spiller med PureMusic og BitPerfect for å se på CPU forbruket der for IRQ etc..

Det eneste jeg kommer til å teste på fremover er om det er mulig å få noe bedre lydkvalitet ut av ARM basert på kernel settinger, sjekke ut om det er noe å hente (lydmessig) på å bruke en SSD i forhold til NAS, og tweake hardware / PSU.
Det lydmessige har jeg ikke hengt meg for mye opp i ennå fordi jeg ville ha den tekniske digitale installsjonen (ARM / Intel hardware og MPD) nogenlunde optimal før tweaking av hardware / PSU.
For min del blir det uten mye tvil ARM hardware jeg kommer til å bruke med en kernel som er tweaket for nettopp ARM hardwaren.
Med Intel er det så langt for mye som ikke fungerer optimalt som gjør det vanskelig å få et optimalt system for lyd...

Det er egentlig vanskelig å forstå hvorfor en i en standard installasjon må bruke 10 ganger så mye CPU kraft på å motta de data som MPD leser inn, buffrer, dekoder og leverer vidre..

Min erfaring så langt er at på Intel platform så er rekkefølgen Windows -> OSX -> Linux når det gjelder lydkvalitet, og at en ARM platform slik som Marvell SoC 510 er et steg videre...
Det fleste andre ARM løsningene (Mac TV inkludert) er teknisk ikke gode og erfaring fra slike må ikke brukes som et grunnlag for å prøve å rangere en Marvell SoC 510 løsnings tekniske og lydmessige potensiale.
Heldigvis leste jeg databladene for flere ARM varianter og så at de fleste har fokus kun på CPU og grafikk, men årsaken er vel at de fleste nye ARM SoC er laget for bruk i mobiltelefoner og lignende...

EDIT: Som en test tok jeg og kompilerte en 3.5.2 kernel til ARM med grafikk etc. (det vil si med all CuBox funksjonalitet inkludert) og spiller ut på både SPDIF og WaveIO USB -> I2S / SPDIF kort...
MPD bruker litt mer CPU (0.5% - top veksler mellom 0.3% og 0.7%) på grunn av en output prosess ekstra, men fortsatt er det så lite CPU forbruk til IRQ at det ikke kan kvantifiseres før etter en lengre periode.

top - 19:15:13 up 30 min,  1 user,  load average: 0.00, 0.01, 0.05
Tasks:  51 total,   1 running,  50 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  0.7 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    638820 total,   392704 used,   246116 free,     1980 buffers
KiB Swap:        0 total,        0 used,        0 free,   286076 cached


  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           
 2174 mpd       rt   0 69348  23m 1904 S   0.3  3.8   0:22.49 mpd               
 2396 root      20   0  8276 2640 2052 S   0.3  0.4   0:01.19 sshd              
 2415 root      20   0  2644 1120  788 R   0.3  0.2   0:00.26 top               
    1 root      20   0  1668  620  520 S   0.0  0.1   0:01.34 init              
    2 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kthreadd          
    3 root      rt   0     0    0    0 S   0.0  0.0   0:00.00 ksoftirqd/0       
    4 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0       
    6 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 khelper           
    7 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kdevtmpfs         
    8 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 netns             
    9 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kworker/u:1       
  213 root      20   0     0    0    0 S   0.0  0.0   0:00.00 sync_supers       
  215 root      20   0     0    0    0 S   0.0  0.0   0:00.00 bdi-default       
  217 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kblockd           
  223 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 ata_sff           
  233 root      20   0     0    0    0 S   0.0  0.0   0:00.00 khubd             
  331 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 rpciod            
  336 root      20   0     0    0    0 S   0.0  0.0   0:00.00 galcore daemon    
  347 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kswapd0           
  348 root      20   0     0    0    0 S   0.0  0.0   0:00.00 fsnotify_mark     
  349 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 nfsiod            
  354 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 crypto            
  451 root      20   0     0    0    0 S   0.0  0.0   0:00.00 scsi_eh_0         
  464 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 orion_spi

I /etc/mpd.conf har jeg for alle output enablet memory mapped IO for alle output.
Hvilke MPD versjonere dette er støttet i er jeg ikke sikker på, men både 0.17.1 og 0.18git fungerer hos meg.

audio_output {
        type            "alsa"
        name            "SPDIF"
        device          "hw:0,0"
#        dsd_usb         "yes"
        auto_format     "no"
        auto_resample   "no"
        use_mmap        "yes"
}

For SPDIF på CuBox er det fortsatt en "bug" slik at det kun er 16bit data som sendes til DAC.
Men både SPDIF og WaveIO kortet fungerer med Memory Mapped IO.

root@ObliMPD:~# cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 4096
buffer_size: 32768
root@ObliMPD:~# cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050
root@ObliMPD:~#

EDIT2:
3.5.3 er nå "stable" og jeg sjekket patch fila for å se hva som er implementert.
For Marvell SoC 510 er det minimale forskjeller, men for andre ARM CPUer er det en god del (som uansett fungerer for Marvell SoC 510 slik jeg har kompilert fordi jeg så problemstillingene), men som kan redusere ytelsen fordi det blir en god del CPU sykluser som brukes ekstra...

Men det som min oppmerksomhet ble rettet mot var følgende for SMP (fler kjerne kode):

/* Wait up to one second for other CPUs to stop */
timeout = USEC_PER_SEC;

Det kan se ut som at fler kjerne systemer kan ha sitt å slite med

 

[nma]

Jepp, dette er hva jeg har gjort også, men jeg har ikke nevnt dette da det ikke er helt 100% stabilt når affinity på interrupts ikke er default.

Ved kompilering av ny kjerne viser er CPU bruk av interrupts ved 1000hz /RT-kjerne/ RT-prioritet på USB-prosess/NRpacks=1 på mellom 0.5 til 1%. ved 192khz og 0.5% under dette (top i squeeze viser bare .0 og .5) Vet ikke om dette er p.g.a er p.g.a utelatte USB-debug-greier, da jeg ikke orket å teste kun dette.
250hz og nrpacks=8 tilsvarer ca null cpu bruk. P.g.a av dette har jeg ikke tatt Oblivion sine "oppdagelser" så veldig alarmerende vedrørende Intel-plattformen..

Når jeg ser på antall interrupts tilsvarer dette 1000hz i sekundet.
Men den nye kjernen låter litt hardere, selv om den kanskje er ørrlite mer oppløst. Og denne blandingen av squeeze/wheezy installasjonen gir meg litt dårlige vibber selv om det tilsynelatende fungerer helt fint. Jeg tror jeg må finne tid en dag og installere wheezy fra bunn av.

Den gamle kjernen bruker ørrlite mer cpu, 1.0 til 1.5% ved 192khz og 1% under dette. CPU bruk av mindre hz og nrpacks=8 tilsvarer vel 0.5% om jeg ikke tok feil.

Oblivion: Hvis du prøver 1000hz/RT-kjerne/nrpacks=1/realtime-prioritet på USB interrupts vil du nok se et annet tall på ARM. Jeg tror altså ikke det er noe magisk med ARM-plattformen.

Det er også glimrende at du har funnet ut at nrpacks=1 er det beste Marsboer. Ved å følge /proc/interrupts med watch-kommandoen vil du se at ved nrpacks=1 tilsvarer omtrent nøyaktig 1000 interrupts pr sekund. Ved bruk av andre verdier blir antallet interrupts i sekundet lavere, men det er ganske lotto i nøyaktigheten i antall pr sekund og i tillegg har antall interrupts/s omtrent ingen relasjon med hva nrpacks tilsier. Innvirkningen på lyden blir IMHO helt likt det man ser, det blir diffust, men vil kunne foretrekkes om akillesen er et annet sted i systemet.

 

[marsboer]

Når jeg sier at jeg så på antall interrupts i forrige innlegg så tenker jeg ikke på NRPACKS og USB interrupts. Dvs NRPACKS = 1ms gir 1000 interrupts /s som du jo ser i ditt system. Jeg tenkte på local timer interrupts i forbindelse med kernel ticks. Det vil si det som CONFIG_HZ justerte direkte i "gamle dager". I tillegg til å analysere output fra /proc/interrupts (dvs LOC) fant jeg et C-program på nett som kjørte tester (dvs faktiske programmessige tester, ikke analyse av f.eks /proc/interrupts) for å finne den faktiske timer interrupt raten på systemet og denne bekreftet at dagens kernels ikke virker å være direkte avhengig av CONFIG_HZ.

http://www.advenage.com/topics/linux-timer-interrupt-frequency.php

Jeg har forøvrig ikke opplevd noen som helst form for stabilitetsproblemer med CPU affinity satt til samme CPU som MPD for IRQ-trådene. Jeg ser ikke helt hvorfor dette skulle oppstå heller, all den tid dette ville gjort single core CPUer nærmest ubrukelige. Det virker litt rått at man må ha minst to kjerner for å dra MPD og USB IRQ samtidig. Det er vanskelig å si om årsaken til ustabiliteten er en uheldig kombinasjon av rt-kernel og programvare/maskinvare eller om det er den egenkompilerte kernelen/mpd som gjør noe muffins som standardvariantene som medfølger Wheezy ikke gjør.

Etter testingen med CONFIG_HZ har jeg uansett gått for det sikre valget og landet på default rt-kernelen som medfølger Debian Wheezy. Dette er en veltestet kernel uten egne hacks fra min side. Jeg har kompilert flere 3.5.1 og 3.5.2 kernels, både nedstrippete og i ulike varianter med f.eks CONFIG_HZ 1000 og PREEMPT (men ingen med RT-patch), men dette har kun tilført kompleksitet i oppsett og mer vedlikehold av boksen uten å tilføre bedre ytelse til mitt formål. Unntaket er selvsagt USB 3.0 og xhci_hcd, men jeg benytter selv den mer pålitelige og gjennomtestede USB 2.0 på Debians standardkernel etter å ha kjørt 3.5.2 med USB 3.0 en stund. Viktige driverfikser vil uansett backportes til 3.2.X på sikt siden denne kernelen er en long term kernel i flere viktige Linux distroer.

 

[marsboer]

Kom på en ting:

Kan det muligens bli problemer om mpd og IRQ-trådene begge har rt-prioritet og CPU affinity er satt til samme CPU? Jeg kjører som nevnt tidligere prioritet 80 på mine mpd-tråder og rt på IRQ-trådene, men om begge har rt-prioritet og ligger på samme CPU så kan det muligens bli problemer siden begge jo jobber parallelt med datastrømmen. I såfall burde ustabiliteten sannsynligvis bli mer fremtredende ved f.eks 24bit 192kHz.

 

[Oblivion]

Jepp, dette er hva jeg har gjort også, men jeg har ikke nevnt dette da det ikke er helt 100% stabilt når affinity på interrupts ikke er default.

Ved kompilering av ny kjerne viser er CPU bruk av interrupts ved 1000hz /RT-kjerne/ RT-prioritet på USB-prosess/NRpacks=1 på mellom 0.5 til 1%. ved 192khz og 0.5% under dette (top i squeeze viser bare .0 og .5) Vet ikke om dette er p.g.a er p.g.a utelatte USB-debug-greier, da jeg ikke orket å teste kun dette.
250hz og nrpacks=8 tilsvarer ca null cpu bruk. P.g.a av dette har jeg ikke tatt Oblivion sine "oppdagelser" så veldig alarmerende vedrørende Intel-plattformen..

Når jeg ser på antall interrupts tilsvarer dette 1000hz i sekundet.
Men den nye kjernen låter litt hardere, selv om den kanskje er ørrlite mer oppløst. Og denne blandingen av squeeze/wheezy installasjonen gir meg litt dårlige vibber selv om det tilsynelatende fungerer helt fint. Jeg tror jeg må finne tid en dag og installere wheezy fra bunn av.

Den gamle kjernen bruker ørrlite mer cpu, 1.0 til 1.5% ved 192khz og 1% under dette. CPU bruk av mindre hz og nrpacks=8 tilsvarer vel 0.5% om jeg ikke tok feil.

Oblivion: Hvis du prøver 1000hz/RT-kjerne/nrpacks=1/realtime-prioritet på USB interrupts vil du nok se et annet tall på ARM. Jeg tror altså ikke det er noe magisk med ARM-plattformen.

Det er også glimrende at du har funnet ut at nrpacks=1 er det beste Marsboer. Ved å følge /proc/interrupts med watch-kommandoen vil du se at ved nrpacks=1 tilsvarer omtrent nøyaktig 1000 interrupts pr sekund. Ved bruk av andre verdier blir antallet interrupts i sekundet lavere, men det er ganske lotto i nøyaktigheten i antall pr sekund og i tillegg har antall interrupts/s omtrent ingen relasjon med hva nrpacks tilsier. Innvirkningen på lyden blir IMHO helt likt det man ser, det blir diffust, men vil kunne foretrekkes om akillesen er et annet sted i systemet.

Har sett på RT patch og sett gjennom hva som er selve RT koden og hva ARM og Intel trenger av spesifikk patching.

Slik jeg ser det så består RT patching av to bestanddeler:
1. Patching av arch/xxx kode (ARM, Intel, Mips etc og litt forskjellig for forskjellige CPU innen arch/xxx).
2. Tillegg av RT kode.

For ARM 510 SoC er det minimalt med endringer i selve koden, men for Intel er det relativt mye endringer som må til.

For ARM 510 SoC er det denne linjen i Kconfig som blir lagt til som er det essensielle:
+ select IRQ_FORCED_THREADING

Fordi RT patchingen gjør at CPU må kjøre mye mer kode uten å oppnå noen gevinst (slik jeg tolker det) for MPD, SPDIF utgangen på ARM SoC 510 eller USB 2.0 portene så lar jeg være å RT patche...
MPD trenger ikke RT kernel, SPDIF på ARM SoC 510 har egen kode og generering av en nøyaktig (extclk) ekstern klokke og USB 2.0 kort som jeg skal bruke har buffring (FIFO) og re-klokking på I2S siden, og med memory mapped I/O mellom MPD og SPDIF / USB 2.0.
Når en setter opp de forskjellige buffer / cache med tilstrekkelig nivå og både SPDIF og USB 2.0 ikke mottar data synkront - data blir buffret og både SPDIF og USB 2.0 får informasjon om samplerate, bitdybde etc. og klokker data ut med sine egne presise klokker basert på denne informasjonen.

Med høyest prioritet til USB / SPDIF, og deretter MPD etc.. og totalt CPU forbruk (på ARM) er (justert opp slik at det er marginer):
44.1k/48k 1%
88.2k/96k 2%
176.4k/192k 4% - 6%
352.8k/384k 8% - 12%
Så bør en PREEMPT kernel med threadirq og riktig oppsatt buffring / caching og prioritets styring gi det beste lydmessig resultatet på en ARM SoC 510 i forhold til en RT kernel fordi en RT kernel konstant må kjøre RT kontroll koden som genererer støy i strømforsyninger etc..

På et Intel system kan det være at RT kernel vil gi det beste lydmessige resultatet fordi RT patchingen forandrer på mye mer av kernel koden, og det er kanskje et større behov pga den høye CPU bruken til IRQ etc..

 

[Oblivion]

Med 3.5.2 kernel med standard CuBox def_config så observerer jeg at SPDIF utgangen ikke trigger interrupts før en begynner å spille.

Every 1.0s: cat /proc/interrupts                        Mon Aug 27 08:19:37 2012


           CPU0
  0:       2500  orion_irq  orion_tick
  7:        357  orion_irq  serial
 11:        846  orion_irq  mv64xxx_i2c
 24:          0  orion_irq  ehci_hcd:usb1
 25:         54  orion_irq  ehci_hcd:usb2
 29:        458  orion_irq  eth0
 35:       5231  orion_irq  mmc0
 36:         52  orion_irq  mmc1
 39:          2  orion_irq  mv_xor.0
 40:          2  orion_irq  mv_xor.1
 42:          2  orion_irq  mv_xor.2
 43:          2  orion_irq  mv_xor.3
 48:          0  orion_irq  galcore interrupt service
 51:          0  orion_irq  ap510-vmeta
 62:          0  orion_irq  sata_mv
 76:          0         -  mmc0
 91:          0         -  TDA IRQ
133:          0   pmu_irq  rtc-mv
Err:          0

Når en spiller så genererer USB veldig mye mer interrupts enn SPDIF.
De har hver sin MPD output prosess, hver sin IRQ, den samme jobben å gjøre etc..

Every 1.0s: cat /proc/interrupts                        Mon Aug 27 08:21:09 2012


           CPU0
  0:       4066  orion_irq  orion_tick
  7:        357  orion_irq  serial
 11:        846  orion_irq  mv64xxx_i2c
 21:        653  orion_irq  kirkwood-i2s
 24:          0  orion_irq  ehci_hcd:usb1
 25:     111884  orion_irq  ehci_hcd:usb2
 29:       1252  orion_irq  eth0
 35:       5344  orion_irq  mmc0
 36:         52  orion_irq  mmc1
 39:          2  orion_irq  mv_xor.0
 40:          2  orion_irq  mv_xor.1
 42:          2  orion_irq  mv_xor.2
 43:          2  orion_irq  mv_xor.3
 48:          0  orion_irq  galcore interrupt service
 51:          0  orion_irq  ap510-vmeta
 62:          0  orion_irq  sata_mv
 76:          0         -  mmc0
 91:          0         -  TDA IRQ
133:          0   pmu_irq  rtc-mv
Err:          0

Skal forsøke å tweake USB og settinger for å se om interrupt nivået kan reduseres / komme ned mot SPDIF nivået.
Skal også teste med 3.5.2 kernel med tweak for å se hva en eventuellt oppnår med det...

 

[marsboer]

Jeg har ikke selv testet PREEMPT grundig opp mot PREEMPT RT, men RT-patchene må til for å kunne preempte critical sections i kernelen. Siden våre systemer knapt gjør noe annet utover mpd/lyd og intern kernelaktivitet, som man jo trenger RT-patchene for å preempte, vil jeg anta at man like godt kan kjøre generic kernel (eller snarere voluntary preempt som egentlig er det som er standard i Debian) med samme resultat som en standard PREEMPT.

Om det vil gi seg lydmessig utslag vet jeg ikke, men i teorien tilsier jo all sunn fornuft at et oppsett som du planlegger skal være nærmest immunt mot variasjoner på PCen.

Men for oss som baserer seg på asynkron isokron USB 2.0, som i praksis innebærer at PCen slaves til klokken i USB-lydkortet, vil det nok gi mere mening.
Min forståelse av asynkron USB 2.0 audio avspilling endret seg etter å ha studert standarddokumentene.

I utgangspunktet hadde jeg den "enkle" forståelsen at ved asynkron USB så dyttes data til USB-lydkortet som igjen klokket dataene ut fra bufferet med sin interne klokke. Med andre ord et oppsett som burde være ganske så immunt mot jitter.

Men etter å ha lest en del i standardspesifikasjonsdokumentene virker det å fungere ganske så annerledes i realiteten. Sånn jeg har forstått det opprettes det i praksis to isokrone enveiskanaler. En for sending av lydstrømmen til lydkortet og en for at lydkortet skal sende data tilbake til PCen. Ved hjelp av sistnevnte sørger USB-lydkortet for å sende pakker etter egen klokke som PCen deretter slaves til, i form av at PCen etter beste evne forsøker å holde seg tro mot klokkesignalet fra USB-lydkortet og dytte data ut med korrekt timing.

Med andre ord er situasjoen ikke slik:
PC -> lydstrøm -> buffer i asynk USB lydkort -> klokking -> utsignal

Men slik:
fast klokke i async USB lydkort -> PC -> lydstrøm synket etter beste evne etter USB klokken -> USB-lydkort -> utsignal

En eventuell gevinst fra asynk USB audio kommer derfor fra antakelsen om at klokken i USB-kortet er mer nøyaktig en det PCen klarer å levere, og at PCens evne til å tilpasse seg det innkommende klokkesignalet er større enn det adaptive USB-lydkortets evne til å gjenvinne klokken fra signalet (med tilhørende dynamisk klokkefrekvenskorreksjon).

Med forbehold om feil forståelse osv...

 

[nma]

Kom på en ting:

Kan det muligens bli problemer om mpd og IRQ-trådene begge har rt-prioritet og CPU affinity er satt til samme CPU? Jeg kjører som nevnt tidligere prioritet 80 på mine mpd-tråder og rt på IRQ-trådene, men om begge har rt-prioritet og ligger på samme CPU så kan det muligens bli problemer siden begge jo jobber parallelt med datastrømmen. I såfall burde ustabiliteten sannsynligvis bli mer fremtredende ved f.eks 24bit 192kHz.

Helt riktig. Må presisere at ustabilitet er ment kun i konteksten lyd/dropouts. Jeg har dog ikke RT-prioritet på MPD. Om jeg har dette, trigger dette en annen ustabilitet i sammenheng med affinity når det resamples med libsamplerate, kun ved 32/352khz+ om jeg husker riktig

Din tolkning av asynkron USB er helt riktig! Asynkron virkemåte blir alltid et subset av isokron/adaptive virkemåte. Og bufferet i en USB DAC må være veldig lite for at det skal jo være rimelig i sync på bilde/lyd. Og sikkert en hel haug av andre ting som spiller inn.

Oblivion:
1. Virker som RT patchen til ARM ikke er annet enn mainline kode med threadirqs.
2. Når ingenting spiller trigges heller ikke noen interrupts her på min Intel-plattform. Alt annet ville vært ulogisk.
3. Jeg kan oppnå tilnærmet 0 i CPU i irq-trådene med Intel også.
4. Det virker som om USB-lydkort har en minimums interrupts/s hardkodet, og alt over 5-6-7-8 alt ettersom blir det samme?
5. Standard kernel gir lavere CPU bruk på Intel, ikke motsatt. Som sagt får jeg dette ned tilnærmet 0.

 

[marsboer]

Jeg har faktisk enda til gode å høre et lydmessig hikk i mitt system, uansett konfigurasjon, men om jeg skulle oppleve noe innenfor min begrensning på 24bit 192kHz så skal jeg si fra.

 

[Oblivion]

1. Virker som RT patchen til ARM ikke er annet enn mainline kode med threadirqs.
2. Når ingenting spiller trigges heller ikke noen interrupts her på min Intel-plattform. Alt annet ville vært ulogisk.
3. Jeg kan oppnå tilnærmet 0 i CPU i irq-trådene med Intel også.
4. Det virker som om USB-lydkort har en minimums interrupts/s hardkodet, og alt over 5-6-7-8 alt ettersom blir det samme?
5. Standard kernel gir lavere CPU bruk på Intel, ikke motsatt. Som sagt får jeg dette ned tilnærmet 0.

Selvfølgelig gir RT kernel et vesentlig høyere CPU forbruk - det er bare å kjenne på kjøleribbene på mitt i5 system så vet en om det er RT eller ikke som kjører "top" viser vel ikke dette (de faktiske forhold)...

Mitt ARM konsept blir stadig mer forskjellig fra det rene Intel RT konseptet med NRPACKS = 1

Hvis du sjekker is source koden (ALSA) så vil du se at et USB adapter blir behandlet forskjellig avhengig av spesifikasjon.
NRPACKS_MAX for 480Mbps (USB 2.0 Audio) har en (xxxxx * konditional koding i forhold til andre USB hastigheter...
Det er også andre parametre som må ses i sammenheng..
Jeg var nødt til å editere source koden for å få andre NRPACKS settinger enn 8 - fordi ALSA også er kompilert inn i kernel.
Og når jeg først skulle endre NRPACKS så sjekket jeg opp resten av koden og gjorde noen flere endringer - blant annet har jeg økt buffer størrelse med 4 ganger..

Foreløpig har jeg satt ned "RT" klokke frekvensen ned til 1/10 fordi alle ingrediensene i systemet nå kan jobbe i en god del sekunder (minutter) uten at det blir "hikke" i lyd avspillingen. Men må nok tweake litt til når jeg begynner å teste 352.8k/384k/24bit/32bit og native DSD64/DSD128.
Foreløpig er det den innebygde SPDIF og USB adaptere som er begrenset til 176.4k/192k som jeg har tweaket for...
Og NRPACKS er nå satt en god del høyere enn 20... Tester med opp til 256 - så det vil vise seg hva som blir det beste etterhvert.

Foreløpig gir (bruker ekstra resursser) fortsatt kernel debug informasjon slik at jeg kan sjekke /proc etc. for data, men dette blir også slått av når jeg får verifisert at en konfigurasjon virker problemfritt.

 

[Oblivion]

NRPACKS

Forøvrig så har ikke NRPACKS noe med millisekund eller interrupt å gjøre direkte,
men indirekte vil det jo gjøre det.

NRPACKS er antall data pakker som sendes pr. urb og er standard satt til 8...
MAX_PACKS er standard satt til 20 for de lavere USB hastighetene,
men for USB 2.0 480Mbit så ganges NRPACKS med en faktor på 8.

Det er rimelig logisk at å sende en og en datapakke med interrupt behandling ikke er den smarteste måten, men heldigvis så blir det 8 med en setting på 1 pga at det er USB 2.0 kort en bruker.
Interrupt antallet vil selvfølgelig øke med lavere NRPACKS verdier.

Jeg har nå forandret på en god del av de parametre som har med dette å gjøre og "andre" har hørt på kernel med 100Hz "RT" klokke og NRPACKS på 32 og en økning i buffer til USB på 64 ganger har ikke hørt noen ulyder

static int nrpacks = 8; /* max. number of packets per urb */

#define MAX_NR_RATES 1024
#define MAX_PACKS 20
#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */
#define MAX_URBS 8
#define SYNC_URBS 4 /* always four urbs for sync */
#define MAX_QUEUE 24 /* try not to exceed this queue length, in ms */

Heldigvis har jeg ikke sort belte i Linux og jeg "stoler" heller ikke på de som mener de er kvalifiserte...

 

[nma]

Det stemmer ikke. Nrpacks 1 tilsvarer 1ms, d.vs 1 frame, med data. USB 2.0 bruker microframes i tillegg. Det går 8 microframes i en vanlig frame.

 

[Oblivion]

Det stemmer ikke. Nrpacks 1 tilsvarer 1ms, d.vs 1 frame, med data. USB 2.0 bruker microframes i tillegg. Det går 8 microframes i en vanlig frame.

Er det du som er sjefen til Linus
Eller er det source koden til linux og de som har skrevet koden som er feil
Fikk du med deg at for USB 2.0 - 480Mbit så ganges det opp med en faktor på 8 ??

Hvis du har lyst til å verifisere så editerer du card.c og card.h i linux-3.x.x/sound/usb og sjekker, og deretter forandrer du NRPACKS fra 8 til en annen verdi.
Kompiler og start maskinen på nytt og sjekk: "cat /sys/module/snd_usb_audio/parameters/nrpacks"
Sjekk deretter source koden og se om NRPACKS er en setting av / i millisekunder eller det du finner i source kode og eventuellt andre steder..

Kan du også forklare hvorfor NRPACKS = 1 skulle tilsvare 1ms på alle maskiner ???
Med CPU klokker som variere fra 100MHz til nærmere 10GHz (overklokking) og med "RT" klokker som varierer fra (100Hz) 200Hz i følge linux source koden til 4000Hz eller mer i praksis slik dere har forklart dette.

 

[Oblivion]

I motsetning til Oblivion er ikke jeg av den oppfatning at det er noe poeng å få all CPU bruk så lav som overhodet mulig.

Det vil medføre lavere støy nivå i strømforsyninger og jord potensialer..

MEN, Oblivion har likevel et godt poeng når han klager på CPU-bruken på Intel platformen kontra f.eks ARM. Det gir ingen mening for meg at dette skal variere så fryktelig, vel og merke gitt at det er samme source code som ligger til grunn for drivermodulene.

Det er de identiske source kode filene som er utgangspunktet FØR kompilering.

Den gode nyheten er imidlertid at jeg har funnet ut hva som er den store synderen. På mitt system aktiveres det av en eller annen grunn to tråder for USB 2.0 hubens IRQ 23, sånn bare til info når du ser på outputen. I tillegg er det verdt å merke seg at "top" kjører med "Irix mode ON" som default, noe som vil si at prosentvis CPU bruk oppgitt for en prosess er i forhold til den CPU-kjernen den kjører på, ikke i forhold til all CPU-kapasitet på systemet. 4% CPU for en prosess i "top" med "Irix mode on" vil dermed si 1% CPU bruk om man ser på alle CPUer totalt i et quad system. Man kan toggle Irix-mode med "I" i top. Alle skjermdumpene er med standardinnstillinger i top, med unntak av at jeg viser alle kjernene øverst.

Jeg vil ikke si at det "er den store synderen" - bare en annen måte å fremstille resultatet på.
Og utgangspunktet er vel det mest korrekte fordi en IRQ prosess blir kjørt på en CPU kjerne.

Dette forklarer også hvorfor et system uten mange kjerner ser vesentlig lavere CPU-bruk på USB out-of-the-box.

Nei der tar du grundig feil og det har jeg forsåvidt beskrevet tidligere...

Med en 4 kjerners CPU hvor hver kjerne klokkes med 2.4GHz (enkelt tall i forhold til en ARM 1 kjerne på 800MHz) og IRQ til USB bruker 2.7% til 8.3% avhengig av USB 2 / USB 3 port og variasjon mellom USB kort.

Det er da 2.7% til 8.3% av 2.4GHz uansett hvilken måte en vil representere det på - det du representerte var at det bare blir 1% eller noe slikt sett i forhold til 9.6GHz sammlet CPU kraft.

Hvis IRQ nivået skulle ha vært like intensivt (antall interrupt pr. sekund eller annen tidsenhet) på en 800MHz CPU med en kjerne skulle CPU forbruket ha vært på 8.1% til 24.9% hvis en regner om forholdet.

Virkeligheten er imidlertid en helt annen ==> Med en SPDIF utgang og to USB 2.0 Audio kort på hver sin USB port med hver sin IRQ - OG det spilles på ALLE tre utgangene OG genereres IRQ for alle tre så er det totale CPU forbruket av 800MHz KUN ca. 1% <-> Hadde det vært en 2.4GHz kjerne så ville det totale CPU forbruket ha vært ca. 0.3% <-> med regnestykket å fordele dette på 4 kjerner (til sammen 9.6GHz) så ville det totale CPU forbruket ha vært ca. 0.075%....

Fordi jeg IKKE har sort belte i linux (lakrissnøre eller hyssing på knærne er vel nærmer sannheten) så har jeg måttet starte på bunnen, men det kommer seg sakte men sikkert når en rent teknisk forstår hardware og greier å lese og forstå source kode..

 

[marsboer]

Jeg vil ikke si at det "er den store synderen" - bare en annen måte å fremstille resultatet på.
Og utgangspunktet er vel det mest korrekte fordi en IRQ prosess blir kjørt på en CPU kjerne.

Dette forklarer også hvorfor et system uten mange kjerner ser vesentlig lavere CPU-bruk på USB out-of-the-box.

Nei der tar du grundig feil og det har jeg forsåvidt beskrevet tidligere...

Med en 4 kjerners CPU hvor hver kjerne klokkes med 2.4GHz (enkelt tall i forhold til en ARM 1 kjerne på 800MHz) og IRQ til USB bruker 2.7% til 8.3% avhengig av USB 2 / USB 3 port og variasjon mellom USB kort.

Det er da 2.7% til 8.3% av 2.4GHz uansett hvilken måte en vil representere det på - det du representerte var at det bare blir 1% eller noe slikt sett i forhold til 9.6GHz sammlet CPU kraft.

Hvis IRQ nivået skulle ha vært like intensivt (antall interrupt pr. sekund eller annen tidsenhet) på en 800MHz CPU med en kjerne skulle CPU forbruket ha vært på 8.1% til 24.9% hvis en regner om forholdet.

Virkeligheten er imidlertid en helt annen...

Fordi jeg IKKE har sort belte i linux (lakrissnøre eller hyssing på knærne er vel nærmer sannheten) så har jeg måttet starte på bunnen, men det kommer seg sakte men sikkert når en rent teknisk forstår hardware og greier å lese og forstå source kode..

Du misforsto hele poenget med innlegget. Basert på det du skriver virker det som om du tror jeg bare skrudde av "irix mode" i Top og derfor fikk en 4x reduksjon i CPU bruk siden CPU-bruken ble fordelt over alle kjernene. Dette blir som du sier helt feil når man sammenligner mot ARM-boksen din, siden det interessante uansett er CPU-bruk per kjerne.

MEN, jeg skrev rimelig klart at CPU-forbedringene var vist med irix mode on, dvs standardoppsettet i "Top". CPU-forbedringen fra nærmest 8% (fordelt på to tråder) til ca 2% var derfor kun relativt til hver kjerne og kun som en følge av CPU affinity endringen til samme cpu som mpd. Hvis jeg slår av irix mode visning slik du påstår at var "synderen" jeg konkluderte med så går CPU-bruken ned til totalt 0.5% CPU-bruk på USB IRQ-trådene.

 

[Oblivion]

MEN, jeg skrev rimelig klart at CPU-forbedringene var vist med irix mode on, dvs standardoppsettet i "Top". CPU-forbedringen fra nærmest 8% (fordelt på to tråder) til ca 2% var derfor kun relativt til hver kjerne og kun som en følge av CPU affinity endringen til samme cpu som mpd. Hvis jeg slår av irix mode visning slik du påstår at var "synderen" jeg konkluderte med så går CPU-bruken ned til totalt 0.5% CPU-bruk på USB IRQ-trådene.

Med "nedjustert" CPU forbruk til ET USB kort / EN IRQ og uten å ta med CPU forbruk til MPD så får du med avslått irix mode 0.5%.
Omregnet tll en 4 kjerne med avslått irix mode og tre MPD output prosesser, tre IRQ prosesser så er mitt ARM resultat 0.075% totalt.
Faktiske forhold er vel da at Intel varianten forbruker 10 - 20 ganger mer CPU i forhold totalt sett av en eller annen årsak...

 

[marsboer]

MEN, jeg skrev rimelig klart at CPU-forbedringene var vist med irix mode on, dvs standardoppsettet i "Top". CPU-forbedringen fra nærmest 8% (fordelt på to tråder) til ca 2% var derfor kun relativt til hver kjerne og kun som en følge av CPU affinity endringen til samme cpu som mpd. Hvis jeg slår av irix mode visning slik du påstår at var "synderen" jeg konkluderte med så går CPU-bruken ned til totalt 0.5% CPU-bruk på USB IRQ-trådene.

Med "nedjustert" CPU forbruk til ET USB kort / EN IRQ og uten å ta med CPU forbruk til MPD så får du med avslått irix mode 0.5%.
Omregnet tll en 4 kjerne med avslått irix mode og tre MPD output prosesser, tre IRQ prosesser så er mitt ARM resultat 0.075% totalt.
Faktiske forhold er vel da at Intel varianten forbruker 10 - 20 ganger mer CPU i forhold totalt sett av en eller annen årsak...

Det er helt riktig, og om dette faktisk er tilfelle med identisk funksjonalitetsnivå så hadde det vært morsomt å finne ut hvorfor.
Jeg ville bare sørge for at du fikk den korrekte forståelsen av mitt tidligere innlegg. Jeg vil jo ikke ha det på meg at jeg tar sneaky shortcuts!

 

[marsboer]

Det stemmer ikke. Nrpacks 1 tilsvarer 1ms, d.vs 1 frame, med data. USB 2.0 bruker microframes i tillegg. Det går 8 microframes i en vanlig frame.

Er det du som er sjefen til Linus
Eller er det source koden til linux og de som har skrevet koden som er feil
Fikk du med deg at for USB 2.0 - 480Mbit så ganges det opp med en faktor på 8 ??

Hvis du har lyst til å verifisere så editerer du card.c og card.h i linux-3.x.x/sound/usb og sjekker, og deretter forandrer du NRPACKS fra 8 til en annen verdi.
Kompiler og start maskinen på nytt og sjekk: "cat /sys/module/snd_usb_audio/parameters/nrpacks"
Sjekk deretter source koden og se om NRPACKS er en setting av / i millisekunder eller det du finner i source kode og eventuellt andre steder..

Kan du også forklare hvorfor NRPACKS = 1 skulle tilsvare 1ms på alle maskiner
Med CPU klokker som variere fra 100MHz til nærmere 10GHz (overklokking) og med "RT" klokker som varierer fra (100Hz) 200Hz i følge linux source koden til 4000Hz eller mer i praksis slik dere har forklart dette.

Her rører du sammen mye rart i en salig saus, uten at jeg mener dette vondt på grunn av kompleksiteten i det som diskuteres.

Det verste først
Linux har ingen problemer med å vedlikeholde en nøyaktig klokke for å klokke ut noe hvert ms helt uanvhengig av klokkefrekvens. Jeg foreslår at du leser manualen for "time". Jeg skal gå over det viktigste her. Først den gamle oppførselen med "jiffies" og CONFIG_HZ som "styrende" parametre.

The Software Clock, HZ, and Jiffies
The accuracy of various system calls that set timeouts, (e.g., select(2), sigtimedwait(2)) and measure CPU time (e.g., getrusage(2)) is limited by the resolution of the software clock, a clock maintained by the kernel which
measures time in jiffies. The size of a jiffy is determined by the value of the kernel constant HZ.

The value of HZ varies across kernel versions and hardware platforms. On i386 the situation is as follows: on kernels up to and including 2.4.x, HZ was 100, giving a jiffy value of 0.01 seconds; starting with 2.6.0, HZ was
raised to 1000, giving a jiffy of 0.001 seconds. Since kernel 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) or 1000, yielding a jiffies value of, respectively, 0.01, 0.004, or 0.001
seconds. Since kernel 2.6.20, a further frequency is available: 300, a number that divides evenly for the common video frame rates (PAL, 25 HZ; NTSC, 30 HZ).

Men som nevnt, er ikke dette oppførselen som jeg ser i nyere kernels. Her er forklaringen:

High-Resolution Timers
Before Linux 2.6.21, the accuracy of timer and sleep system calls (see below) was also limited by the size of the jiffy.

Since Linux 2.6.21, Linux supports high-resolution timers (HRTs), optionally configurable via CONFIG_HIGH_RES_TIMERS. On a system that supports HRTs, the accuracy of sleep and timer system calls is no longer constrained by the
jiffy, but instead can be as accurate as the hardware allows (microsecond accuracy is typical of modern hardware). You can determine whether high-resolution timers are supported by checking the resolution returned by a call to
clock_getres(2) or looking at the "resolution" entries in /proc/timer_list.

HRTs are not supported on all hardware architectures. (Support is provided on x86, arm, and powerpc, among others.)

Hvis du leser litt i dette dokumentet: http://www.kernel.org/doc/Documentation/timers/hrtimers.txt
...ser du at følgende overordnet funksjonalitet gjelder for high res timers som benyttes i kernelen i dag - gitt at du ikke har deaktivert highres timers når du kompilerte kernel:

- data structure not bound to jiffies or any other granularity. All the kernel logic works at 64-bit nanoseconds resolution - no compromises.
- simplification of existing, timing related kernel code

Deretter angående nrpacks:
USB fungerer slik at det klokkes ut en pakke hvert millisekund. USB 2.0 sender som Man nevner, og som du er inne på indirekte, imidlertid ut såkalte microframes hvert 0.125 sekund. Dette styres da av "#define MAX_PACKS_HS (MAX_PACKS * 8)" i kildekoden. NRPACKS, eller number of packs i fullt utskrevet form, regulerer hvor mange packs, det vil si fulle frames, ikke mikroframes, som skal sendes ut for hver URB. Med NRPACKS = 8 vil det sendes ut 8 packs (frames) per URB, det vil si at det tar 8 ms før en URB sendes siden hver frame er 1 ms uansett.
For hver av disse frames lages det en microframe hvert 0.125 sekund på USB 2.0. Det vil si at i praksis har det gått 8 x 8 microframes i denne tidsperioden.

Forvirringen oppstår imidlertid siden kernelen ikke skiller på frame og microframe i source kode terminologien. Der kalles alt "packs". Dette medfører komplikasjoner om man tolker NRPACKS direkte som "number of packs per URB" siden antallet packs er 8 ganger høyere for USB 2.0 uten at dette reflekteres i NRPACKS.
Om man skulle beskrive NRPACKS parameteren med terminologien brukt andre steder betyr NRPACKS egentlig "number of full frames per URB". Det at det går 8 microframes per frame endrer ikke fortolkningen av NRPACKS parameteren med denne terminologien noe som gir enklere forståelse av parameteren.

Med vissheten om at en frame alltid er 1 ms vil det da som en konsekvens være slik at NRPACKS = X antall full frames også betyr X antall millisekunder.

How to transfer data to USB isochronous endpoints

 

[Oblivion]

Det blir mye ironi ut av dette...

For å sette det hele i perspektiv:

Med UAC1 1.5Mbit så er / var vel NRPACKS = 8 et nogenlunde brukbart parameter for å holde IRQ innenfor et "akseptabelt" nivå samtidig som en skulle få data over uten alvorlige flaskehalser.
Når 12Mbit ble tatt i bruk burde NRPACKS ha vært økt med 8 ganger eller en 8x funksjon ha vært implemtert i driver på det tidspunktet.
Denne 8x funksjonen kom ikke før UAC2 med 480Mbit kom, men da burde NRPACKS ha vært økt med 256 ganger eller en 256x funksjon implementert i driver.
Dette for å holde IRQ nivå på et akseptabelt nivå i forhold til kapasiteten i de forskjellige standardene.

Det første ironiske er at UAC1 12Mbit ga dårlig lydkvalitet og at UAC2 med 480Mbit ga mye bedre lydkvalitet.
Det ironiske er at det mest sannsynlig var økningen på 8 ganger av NRPACKS i driver som var det som ga lydforbedringen og ikke økningen fra 12Mbit til 480Mbit fordi de var de samme 44.1k/16bit musikk filene som ble spilt / overført og UAC1 12Mbit har ingen problemer med det.

Det andre ironiske er at når jeg nå har endt på NRPACKS = 32 som et minimum for god lydkvalitet med UAC2 480Mbit så er det effektivt 32 ganger 8 som er 256 ganger høyere NRPACKS sammenlignet med UAC1 1.5Mbit, og dette burde ha vært skalert etter som standardene har skalert..

Nå skal jeg teste ut om NRPACKS trenger å være enda høyere, fra 44.1k/16bit til 352.8k/32bit er det 8 til 16 ganger større data mengde som skal overføres og det er ikke umulig at optimal NRPACKS verdi da kan ligge i området 32 - 256 (igjen ganget med 8 av driveren)..

Det er også ironisk at en NRPACKS verdi på 1 har vært hevdet å være optimal - både det faktum at 1 egentlig er 8 fordi driveren ganger automatisk med 8 når UAC2 480Mbit blir detektert, og at lydkvaliteten da blir mer anstrengt og lik den lydkvaliteten en hadde med UAC1.
Dette siste fenomenet er noe jeg har sett gang på gang og det har noe med at den lyd signaturen en har vært vant til er den det er lettest å fortsette med.

[ironi på] Så både scriptet til marsboer og man får endre måleenheten fra 1ms til 1/8ms eller blir det 8ms [ironi av]

 

[marsboer]

Jeg må innrømme at jeg ikke hang helt med på innlegget ditt, men det tar jeg på egen kappe

Hvert 0.125 ms lages det en pakke. Denne kan enten være stor eller liten avhengig av dataraten på lyden, men antallet pakker øker vel strengt tatt ikke. Jeg ser derfor ikke at det gir mening å regulere NRPACKS i forhold til dataratene.

Det som er helt sikkert er at laveste latency kommer med 1, dvs en URB per pakke og dermed en interrupt, mens laveste CPU-bruk kommer med høyere verdier, men med noe høyere latency.

Spørsmålet er hvilke av disse som er av mest betydning (om det i det hele tatt er relle hørbare forskjeller)

 

[marsboer]

Som en gest til deg Oblivion, og fordi det strengt tatt er mest korrekt terminologimessig, har jeg endret scriptet

Før:
snd-usb-audio nrpacks is set to 1 ms

Etter:
snd-usb-audio nrpacks is set to 1 1ms packs per URB

1ms packs per URB er egentlig den beste "måleenheten" for NRPACKS, i og med at den får frem differansen mellom 1 ms packs og 0.125 ms packs på en måte som gjør at tolkningen av NRPACKS forblir fast, uavhengig av USB 1.1 eller USB 2.0.

 

[Oblivion]

1ms packs per URB er egentlig den beste "måleenheten" for NRPACKS, i og med at den får frem differansen mellom 1 ms packs og 0.125 ms packs på en måte som gjør at tolkningen av NRPACKS forblir fast, uavhengig av USB 1.1 eller USB 2.0.

Når en setter NRPACKS=1 så betyr det 8 stykk packs per URB med et UAC2 kort...

Er ikke sikker på hva som er den beste "måleenheten",
men for meg spiller det liten rolle da dette blir kompilert inn i kernel,
og med modifisert kode slik at det blir forskjellige parametre basert på hastigheten på gjeldende tilkoblede USB enhet.

 

[marsboer]

Jeg forstår fremdeles ikke hvorfor du vil endre NRPACKS avhengig av om det er USB 1.1 eller 2.0. Det er jo trossalt kun utsending av URBen som reguleres med NRPACKS og verdien gir samme effekt avhengig av om det er USB 1.1 eller 2.0. URBen sendes ved identiske intervaller i begge tilfeller med samme NRPACKS verdi. Det at det sendes 8 microframes med USB 2.0 er ikke av betydning i det hele tatt for utsendingsintervallet for URBen som NRPACKS regulerer. Det virker som om du mener NRPACKS regulerer antall pakker som sendes ut, noe parameteren altså ikke gjør.

 

[Oblivion]

Jeg forstår fremdeles ikke hvorfor du vil endre NRPACKS avhengig av om det er USB 1.1 eller 2.0. Det er jo trossalt kun utsending av URBen som reguleres med NRPACKS og verdien gir samme effekt avhengig av om det er USB 1.1 eller 2.0. URBen sendes ved identiske intervaller i begge tilfeller med samme NRPACKS verdi. Det at det sendes 8 microframes med USB 2.0 er ikke av betydning i det hele tatt for utsendingsintervallet for URBen som NRPACKS regulerer. Det virker som om du mener NRPACKS regulerer antall pakker som sendes ut, noe parameteren altså ikke gjør.

Antall URBS er hardkodet til maksimum 8.
Størrelsen på URB er definert slik: int packet_size[MAX_PACKS_HS]; /* size of packets for next submission */
Altså er det en total begrensning på 8 URBS med en størrelse som vist over.


int index; /* index for urb array */
int packets; /* number of packets per urb */
int packet_size[MAX_PACKS_HS]; /* size of packets for next submission */



packets = antall packets pr. URB.
packets får sin verdi fra NRPACKS settingen.

NRPACKS som angir "packets" verdi kan settes mellom 1 og verdien i MAX_PACKS (20).

MAX_PACKS_HS er hardcodet til 20 * 8 = 160 - som brukes for UAC2.

Da er det ved NRPACKS 1: 1 packets pr. URB og størrelsen på URB er 160 ganger mot 20 ganger ved UAC1
Da er det ved NRPACKS 20: 20 packets pr. URB og størrelsen på URB er 160 ganger mot 20 ganger ved UAC1

Det må da sendes 20 gangers så mange URB ved NRPACKS satt til 1.
Med NRPACKS satt til 20 så sendes det 20 ganger så mye data pr. URB.

Med kun 8 URB tilgjengelig så må NRPACKS opp til 3 for at en skal klare den samme dataraten (med mye mer IRQ for å få det til).
NRPACKS satt til 1 vil da redusere båndvidden ned til ca. 1/3 på USB bus...

Hmm... fortsatt kan jeg ikke se (og ikke funnet i source koden) at NRPACKS har en dobbelt definering som skal gi denne berømte 1ms eller 8ms eller 1/8ms

Det eneste jeg kan finne med en henvisning til ms er:

define MAX_QUEUE 24 /* try not to exceed this queue length, in ms */

De berømte 8 stk. micro framene har jeg heller ikke funnet i source koden ennå -
drivers/usb/core eller sound/usb

Med en maksimal kø lengde i tid på 24ms og med maksimalt 8 URBS,
og det er disse verdiene som er brukt i kernel 3.5.2 (har ikke sjekket eldre)
så kan jeg ikke forstå noe annet enn at 24ms / 8 = 3ms..
Det burde tilsi si at en URB kan bruke opp til 3ms..

Hmmm.... Jeg stoler faktisk mest på den source koden jeg har lastet ned fra kernel.org og som jeg har kompilert og bruker...
Som jeg har oppdaget selv OG har blitt gjort oppmerksom på så skal en ikke stole på noe som er skrevet for et år eller to siden når det gjelder linux.

 

[marsboer]

Joda, alt finnes i source coden, alt i fra bruken av micro frames (også kalt uframe) og reguleringen av tidsintervallet. Dette reguleres av urb->interval i drivers/usb/core/urb.c:

Sjekk den detaljerte dokumentasjonen for funksjonen "usb_submit_urb" i filen.
Et utdrag:

Periodic transfers (interrupt or isochronous) are performed repeatedly,
using the interval specified in the urb. Submitting the first urb to
the endpoint reserves the bandwidth necessary to make those transfers.
If the USB subsystem can't allocate sufficient bandwidth to perform
the periodic request, submitting such a periodic request should fail.

Verdien bestemmes litt lengre ned for de ulike USB-hastighetene

switch (dev->speed) {
case USB_SPEED_SUPER: /* units are 125us */
/* Handle up to 2^(16-1) microframes */
if (urb->interval > (1 << 15))
return -EINVAL;
max = 1 << 15;
break;
case USB_SPEED_WIRELESS:
if (urb->interval > 16)
return -EINVAL;
break;
case USB_SPEED_HIGH: /* units are microframes */
/* NOTE usb handles 2^15 */
if (urb->interval > (1024 * 8))
urb->interval = 1024 * 8;
max = 1024 * 8;
break;
case USB_SPEED_FULL: /* units are frames/msec */
case USB_SPEED_LOW:
if (xfertype == USB_ENDPOINT_XFER_INT) {
if (urb->interval > 255)
return -EINVAL;
/* NOTE ohci only handles up to 32 */
max = 128;
} else {
if (urb->interval > 1024)
urb->interval = 1024;
/* NOTE usb and ohci handle up to 2^15 */
max = 1024;
}
break;
default:

Opprettelse av URB og tilsvarende initieres fra drivers/usb/usb-skeleton.c hvor mye av kjørelogikken ligger.

Denne funksjonen gjør så vidt jeg kan skjønne den viktigste jobben (drivers/usb/devio.c): proc_do_submiturb.

Det finnes også funksjoner for å hente ut og presenteret URB intervallet i både endpoints.c og devices.c som refererer til det samme av intervaller.

interval *= (speed == USB_SPEED_HIGH ||
speed == USB_SPEED_SUPER) ? 125 : 1000;
if (interval % 1000)
unit = 'u';
else {
unit = 'm';
interval /= 1000;
}

Det er såpass mye kildekode å ta innover seg, og jeg er ingen C-ekspert, men det refereres til 1 ms "normalintervaller" og 0.125 ms microframe for high speed (eller uframe som de kaller det i kildekoden) intervaller alle logiske steder i kildekoden.
Det holder ikke å bare kikke på statiske definisjoner øverst slik du gjør. Du må se på selve logikken, og du har mange lange dager foran deg om du ønsker å forstå alt som skjer. Jeg er også helt sikker på at du ender opp på samme konklusjon når du etterhvert får oversikt og full forståelse. Akkurat nå trekker du en rekke slutninger basert på feil grunnlag. Jeg tror faktisk at de som har skrevet kildekoden har tenkt såpass mye gjennom dette at "amatører" som oss uten C-bakgrunn egentlig kan tilføre noe som helst uten flere års erfaring med de intrikate detaljene i USB.

 

[Oblivion]

switch (dev->speed) {
case USB_SPEED_SUPER: /* units are 125us */
/* Handle up to 2^(16-1) microframes */
if (urb->interval > (1 << 15))
return -EINVAL;
max = 1 << 15;
break;
case USB_SPEED_WIRELESS:
if (urb->interval > 16)
return -EINVAL;
break;
case USB_SPEED_HIGH: /* units are microframes */
/* NOTE usb handles 2^15 */
if (urb->interval > (1024 * 8 ))
urb->interval = 1024 * 8;
max = 1024 * 8;
break;
case USB_SPEED_FULL: /* units are frames/msec */
case USB_SPEED_LOW:
if (xfertype == USB_ENDPOINT_XFER_INT) {
if (urb->interval > 255)
return -EINVAL;
/* NOTE ohci only handles up to 32 */
max = 128;
} else {
if (urb->interval > 1024)
urb->interval = 1024;
/* NOTE usb and ohci handle up to 2^15 */
max = 1024;
}
break;
default:


Det er såpass mye kildekode å ta innover seg, og jeg er ingen C-ekspert, men det refereres til 1 ms "normalintervaller" og 0.125 ms microframe for high speed (eller uframe som de kaller det i kildekoden) intervaller alle logiske steder i kildekoden.
Det holder ikke å bare kikke på statiske definisjoner øverst slik du gjør. Du må se på selve logikken, og du har mange lange dager foran deg om du ønsker å forstå alt som skjer. Jeg er også helt sikker på at du ender opp på samme konklusjon når du etterhvert får oversikt og full forståelse. Akkurat nå trekker du en rekke slutninger basert på feil grunnlag. Jeg tror faktisk at de som har skrevet kildekoden har tenkt såpass mye gjennom dette at "amatører" som oss uten C-bakgrunn egentlig kan tilføre noe som helst uten flere års erfaring med de intrikate detaljene i USB.

Det er USB 3 som er SPEED_SUPER og i tilfellet bruker 125us
Det er USB 2.0 som er SPEED_HiGH og for USB 2.0 brukes uttrykket "microframes" men hvor du har ditt 1ms fra skjønner jeg fortsatt ikke.
For SPEED_FULL (12Mbit) og SPEED_LOW (1.5Mbit) brukes uttrykket "units are frames/msec"...

1024 * 8 som er intervallet med USB 2.0 kommer vel fra det følgende: MAX_NR_RATES * NRPACS som standard er 8....

#define MAX_NR_RATES 1024
#define MAX_PACKS 20
#define MAX_PACKS_HS (MAX_PACKS * 8 ) /* in high speed mode */
#define MAX_URBS 8
#define SYNC_URBS 4 /* always four urbs for sync */
#define MAX_QUEUE 24 /* try not to exceed this queue length, in ms */

Det er ikke referert til 1ms "normalintervaller" slik jeg forstår det - er det uttrykket "microframes" du oversetter til 1ms.

Selv 1.5Mbit SPEED_LOW er definert som "units are frames/msec" og jeg kan ikke forstå annet enn at "units" kan være opp til 1024.
Altså 1/1024 dels ms som ytter punkt.


for USB 2.0 er det beskrevet:

urb->interval = 1024 * 8 => 8192

8192 er da et maksimalt URB intervall og det får jeg heller ikke til å gå opp med 1ms.

@marsboer jeg tror at du og @man eller meg er ute og sykler fordi "kart og terreng" ikke ser ut til å stemme og jo mer vi "sjekker" jo dårligere stemmer det...

 

[marsboer]

Stemmer perfekt her. || betyr or på kodesyntaks. Med andre ord er interval 125/1000 for High eller super og 1000 mikrosek for low speed. Alt jeg har lest av kildekode og teori stemmer med all dokumentasjonen. Det er kun din tolkning som er helt avvikende.

 

[marsboer]

For å være litt mer konstruktiv. Magien skjer faktisk ikke i drivers/ i det hele tatt. Sjekk include/linux/usb.h.

Utdrag fra funksjonen usb_fill_int_urb som så vidt jeg har forstått fyller URB med korrekte data, og som blant annet initialiserer interval-verdien. Disse funksjonene er så vidt jeg skjønner "hjelpefunksjonene" som det refereres til i drivers/ filene hele tiden.

 * usb_fill_int_urb - macro to help initialize a interrupt urb
 * @urb: pointer to the urb to initialize.
 * @dev: pointer to the struct usb_device for this urb.
 * @pipe: the endpoint pipe
 * @transfer_buffer: pointer to the transfer buffer
 * @buffer_length: length of the transfer buffer
 * @complete_fn: pointer to the usb_complete_t function
 * @context: what to set the urb context to.
 * @interval: what to set the urb interval to, encoded like
 *  the endpoint descriptor's bInterval value.
 *
 * Initializes a interrupt urb with the proper information needed to submit
 * it to a device.
 *
[SIZE=4][B] * Note that High Speed and SuperSpeed interrupt endpoints use a logarithmic
 * encoding of the endpoint interval, and express polling intervals in
 * microframes (eight per millisecond) rather than in frames (one per
 * millisecond).[/B][/SIZE]
 *
 * Wireless USB also uses the logarithmic encoding, but specifies it in units of
 * 128us instead of 125us.  For Wireless USB devices, the interval is passed
 * through to the host controller, rather than being translated into microframe
 * units.

Særlig klarere enn dette kan du vel ikke få det? Dette står i tillegg i den relevante funksjonen i kildekoden, ikke i et annet dokument.
Slik jeg ser det kan jeg enten godta dette, eller sette meg inn i alle detaljene og finurlighetene i den omfattende kildekoden uten ballast hverken i C eller USB-driverutvikling.

Jeg velger det første

Merk forøvrig "logarithmic", jeg mener jeg leste log2 et sted, med andre ord kan ikke urb->interval verdiene tolkes rett frem.

 

[coolbiz]

For meg er dette forumets mest Interessante tråd, for tiden. Har lenge gått med tanken om å mekke i hop en MPD-avspiller, men må innrømme at jeg blir litt betenkt over hvor hørbart småjusteringer på drivernivå påstås å være.

Det synes å være litt forvirring om C-syntaks.
Denne sekvensen:

interval *= (speed == USB_SPEED_HIGH ||
speed == USB_SPEED_SUPER) ? 125 : 1000;

betyr det samme som:

if (speed == USB_SPEED_HIGH || speed == USB_SPEED_SUPER)

interval = interval * 125;​

else

interval = interval * 1000;​

der || som nevnt betyr OR. (logisk OR og ikke bitvis OR)

mens uttrykket

(interval % 1000)

er sant dersom interval ikke er en multippel av 1000.

 

[marsboer]

Takk for oppklaring. Jeg har som nevnt så godt som ingen erfaring med c, så det er bra du kan komme med litt påfyll.

 

[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.

 

[Goophy]

For meg er dette forumets mest Interessante tråd, for tiden. Har lenge gått med tanken om å mekke i hop en MPD-avspiller, men må innrømme at jeg blir litt betenkt over hvor hørbart småjusteringer på drivernivå påstås å være.

Jeg ville ikke vært altfor bekymret.
Selv hører jeg absolutt ingen forskjell på tingene som har blitt diskutert de siste sidene.
Lever godt med et par ekstra interrupts, ingen realtime-kernel og masse ekstra moduler.

Kjører man alsa rett mot hardware-devicen og bruker standardinnstillinger fungerer det virkelig bra!

 

[marsboer]

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]

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?

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.

 

[marsboer]

Jeg kjenner på meg selv at jeg må unnlate å dra dette videre..

 

[Oblivion]

For meg er dette forumets mest Interessante tråd, for tiden. Har lenge gått med tanken om å mekke i hop en MPD-avspiller, men må innrømme at jeg blir litt betenkt over hvor hørbart småjusteringer på drivernivå påstås å være.

Jeg ville ikke vært altfor bekymret.
Selv hører jeg absolutt ingen forskjell på tingene som har blitt diskutert de siste sidene.
Lever godt med et par ekstra interrupts, ingen realtime-kernel og masse ekstra moduler.

Kjører man alsa rett mot hardware-devicen og bruker standardinnstillinger fungerer det virkelig bra!

Goophy har også prøvd kernel med NRPACKS = 32 / MAX_PACKS = 256 og en del andre tweakede settinger.
Og forskjellene er ikke store så lenge tweakene gjør oppsettet mer optimalt.
Kernel med disse settingen hadde også ("RT" prioriteter på IRQ og MPD og) 100Hz "RT" timer og MPoD falt ut i et sekund eller to iblant (hos meg), og jeg trengte en second opinion på om det spilte "normalt" eller om det ga noen problemer i et annet oppsett - noe det ikke gjorde. Hos meg (ferie huset) har jeg hatt mye trøbbel med iPad og MPoD mot MPD og også MacBook Air (Window system på det trådløse nettet ??) og da er det greit med en dobbelt sjekk

 

[marsboer]

@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.

 

[nma]

@marsboer jeg tror at du og @man eller meg er ute og sykler fordi "kart og terreng" ikke ser ut til å stemme og jo mer vi "sjekker" jo dårligere stemmer det...

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,
se f.eks her: [PATCH] ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()
M.a.o er dette er kode for å hindre en USB-exploit og har nada med utledningen din å gjøre.


Videre fra MSDNET:

For the example, these are the array entries for the transfer buffer in full speed. In full speed, the client driver has one frame to transfer one isochronous packet up to 1,023 bytes. A transfer buffer of 25,575 bytes can hold 25 isochronous packets, each 1,023 bytes long. A total of 25 frames are required for the entire buffer.

For the example, these are the array entries for a transfer buffer in high speed. The example assumes that the buffer is 24,576 bytes, and the client driver has one frame to transfer eight isochronous packets, each 3,072 bytes long.

For the example, this is the array offset for SuperSpeed. You can transfer up to 45,000 bytes in one frame. The transfer buffer of size 360,000 fits within eight microframes.

Videre følger det at isokrone USB 1.0-overføringer har en max bitrate/s på 1023x1000x8 = 8184000 bits
PCM data ved 24/96 har en bitrate på 24x96000x2 = 4608000 bits (innenfor USB1 isokron/UAC1 spec)
PCM data ved 24/176,4 har en bitrate på 24x176400x2= 8572200 bits (utenfor USB1 isokron/UAC1 spec)
Det er ingen standardiserte lydstandarder m.h.t bit/frekvens mellom 24/96 24/172,4 , og således er derfor 24/96 det praktiske maximum som støttes på UAC1-lydkort.

(Faktisk er både 20/176.4 og 20/192 innenfor den isokrone USB 1-speccen, men som sagt er dette ikke standardiserte formater)

 

[nma]

Jeg har faktisk enda til gode å høre et lydmessig hikk i mitt system, uansett konfigurasjon, men om jeg skulle oppleve noe innenfor min begrensning på 24bit 192kHz så skal jeg si fra.

Dette skjedde bare plutselig, og jeg har revet meg litt i håret p.g.a av dette. Men jeg tror jeg fant grunnen.
Grunnen til ubstabiliteten v var p.g.a at affinity var forskjellig fra USB1 og USB2. Det sitter begge typer kontrollere i en USB2-kontroller, og datastrømmen rutes til riktig kontroller alt ettersom. Så det er kanskje logisk at dette bør være samme affinity. Men, det gjorde ingen utslag FØR jeg skiftet affinity på MPD. Først da affinity for MPD ble forandret fra default, ble det et problem. Og nå virker det som om en nedstrippet kernel ikke lengre fører til hardere lyd, men bare enda ørrlite mer oppløst lyd. Men det må jeg dobbeltsjekke. Har ikke hatt tid å bruke anlegget den siste uka.