Gå til innhold

Den frie kafeen


Anbefalte innlegg

Videoannonse
Annonse

Problemet med PulseAudio er en blanding av latterlig høy latency og skipping i lyden. Det er en av grunnene til at jeg sitter på Windows istedenfor linux akkurat nå. Vi lever i 2014, slike ting er teknisk mulig å løse - og de var løst, for både 10 og 15 år siden.

 

OSS var ubrukelig sist jeg testet det. Bare en så enkel ting som å koble et headset til og fra for steam funker sømløst med Pulseaudio. Å styre lyd på musikk uavhengig av spill funker også. Å dele ut lyden til andre dingser i huset er også enkelt. En volumkontroll i stedet for å dille med alsamixer funker flott. Klart skille mellom driver (alsa) og user space (pulseaudio) er en stor teknisk fordel. CPU og minne bruken er lav sammenlignet med det meste, kun interresant problemstilling for bruk på routere, rasPi og foreldet maskinvare. Nyt fremtiden og la OSS for guds skyld dø i fred, jeg prøver desperat å fortrenge det helvete oss gjengen påførte oss alle.

OSS4 har også uavhengige volumkontroller per program, forveksler du OSS4 med OSS i kjernen? Dette er to uavhengig systemer som implementerer lignende API.
Lenke til kommentar

Pulseaudio/ALSA har funket veldig bra for meg de siste årene. Vet ikke om det er tilfeldigheter eller noe med oppsettet. Dac'en funker også fjell. Det eneste som irriterer er at jeg ikke kan bruke Pulseaudio devices via Wine, men det er nok mer Wine sitt problem.

Lenke til kommentar

Problemet med PulseAudio er en blanding av latterlig høy latency og skipping i lyden. Det er en av grunnene til at jeg sitter på Windows istedenfor linux akkurat nå. Vi lever i 2014, slike ting er teknisk mulig å løse - og de var løst, for både 10 og 15 år siden.

Pulseaudio har bra latency for de aller fleste formål. For lydproduksjon bruker du Jack istedet, så får du latency som slår det meste. Skipping i lyden har jeg ikke lagt merke til, hva er det du sikter til her?

OSS4 har også uavhengige volumkontroller per program, forveksler du OSS4 med OSS i kjernen? Dette er to uavhengig systemer som implementerer lignende API.

Nei, OSS er OSS, OSS4 er siste versjon. Et krampeaktig forsøk på å ta igjen Pulseaudio som i dag er overlegen på de aller fleste områder. Som jeg sa har jeg ikke fulgt med OSS de siste årene, så hva de har klart å endelig knote inn i den kodebasen har jeg ikke oversikt over, og jeg har ikke tenkt å brenne av særlig mange kalorier på det heller. De hadde sin sjanse og dreit seg ut.

http://en.wikipedia.org/wiki/Open_Sound_System#Free.2C_proprietary.2C_free

Lenke til kommentar

Nei, OSS er OSS

Tja, OSS i Linux-kjernen og OSS4 var ute av sync, så hvis du bare valgte OSS når du kompilerte kjernen så fikk du noe hauggammelt drit som lå 5 år etter og ikke hadde støtte for per-program volumkontroller og jacksense (automatisk bytte mellom høyttaler og hodetelefon).

 

Pulseaudio har bra latency for de aller fleste formål.

Enten så er den bra, eller så er den ikke bra. Sånn det var før la PulseAudio på ekstra latency oppå alsa. En dobling av latency (og i noen tilfeller tidobling) i forhold til det som er teknisk banalt enkelt å få til er per definisjon ikke bra, uavhengig av det faktiske antall millisekunder som brukes.

 

I praksis så er den heller ikke bra. Jeg lastet ned siste versjon av Linux mint kun for å teste dette, og når jeg drar den globale volumkontrollen opp og ned så henger lyden etter. Det kjennes ut som minst dobling av latency i forhold til hva ren ALSA pleide å gi.

 

Når jeg trykker Pause skal lyden stoppe umiddelbart. Den skal ikke stoppe etter 300 millisekunder. Og ditto med play.

 

Skipping i lyden har jeg ikke lagt merke til, hva er det du sikter til her?

Du vet sånn knirk/knepp som kommer når man setter for lav latency og systemet får buffer underrun et eller annet sted? F.eks. under 20 ms bruker et "vanlig" lydsystem som ALSA å få problemer, mens ASIO kan gå ned til 5 med et bra lydkort. Men med PulseAudio kan det komme i hytt og gevær. Dette er et problem som mange har hatt helt siden starten.

 

For lydproduksjon bruker du Jack istedet, så får du latency som slår det meste.

Dette burde vært unødvendig. Det er ingen naturlov som sier at man ikke kunne lagd et system med funksjonene til PulseAudio som også fungerte like bra som Jack (som CoreAudio på Mac). Men de valgte å la være.
Lenke til kommentar
Enten så er den bra, eller så er den ikke bra. Sånn det var før la PulseAudio på ekstra latency oppå alsa. En dobling av latency (og i noen tilfeller tidobling) i forhold til det som er teknisk banalt enkelt å få til er per definisjon ikke bra, uavhengig av det faktiske antall millisekunder som brukes.

Ja, PA legger på latency, men det er for at du skal få en bedre brukeropplevelse. Nettopp for å unngå skipping og for å senke strømforbruk. To problemstillinger du ikke har på et lydproduksjonsanlegg. Latency er bra for vanlig bruk, og mye bedre enn du fremstiller det.

 

I praksis så er den heller ikke bra. Jeg lastet ned siste versjon av Linux mint kun for å teste dette, og når jeg drar den globale volumkontrollen opp og ned så henger lyden etter. Det kjennes ut som minst dobling av latency i forhold til hva ren ALSA pleide å gi.

 

Når jeg trykker Pause skal lyden stoppe umiddelbart. Den skal ikke stoppe etter 300 millisekunder. Og ditto med play.

Nå har jeg testet med diverse lydklipp, lyd opp og ned, pause av og på. Jeg klarer ikke å merke *noe* forsinkelse. Spørs om det er noe tull med oppsettet ditt.

Du vet sånn knirk/knepp som kommer når man setter for lav latency og systemet får buffer underrun et eller annet sted? F.eks. under 20 ms bruker et "vanlig" lydsystem som ALSA å få problemer, mens ASIO kan gå ned til 5 med et bra lydkort. Men med PulseAudio kan det komme i hytt og gevær. Dette er et problem som mange har hatt helt siden starten.

Pulseaudio benket til 20ms latency på en galaxy nexus som kjører Android (altså meget svak hardware med betydelig behov for strømsparing):

http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/

Legg merke til ressursbruk mot audioflinger, pulseaudio er et meget solid stykke programvare. Jeg kan ikke huske å hørt noe knirk/knepp, sikker på at du ikke har brukt odde oppsett på pulseaudio? Pulseaudio har dynamisk håndtering av latency, det er for å unngå buffer underrun. Med standard oppsett skal dette ikke være noe problem med pulseaudio, det er en av fordelene ved pulseaudio.

Dette burde vært unødvendig. Det er ingen naturlov som sier at man ikke kunne lagd et system med funksjonene til PulseAudio som også fungerte like bra som Jack (som CoreAudio på Mac). Men de valgte å la være.

 

Såvidt jeg har forstått tilbyr coreaudio verken funksjonaliteten eller latency på linje med Jack, men kom gjerne med dokumentasjon. Dessuten knakk vel coreaudio omtrent det som var av kompatiblitet for å komme dit de er. Pulseaudio støtter det meste av applikasjonstacken, det er mye teknisk arv der for å gjøre alle sære linuxbrukere fornøyd. Jack driter i det, og gir deg maks ytelse. Kombiner det med en real-time kjerne, så vil jeg like å se at Coreaudio er konkurransedyktig, men vi snakker her om profesjonell lydproduksjon. For vanlig bruk er Pulseaudio meget god. Her er en god kilde:

http://0pointer.de/blog/projects/when-pa-and-when-not.html

Lenke til kommentar

 

Enten så er den bra, eller så er den ikke bra. Sånn det var før la PulseAudio på ekstra latency oppå alsa. En dobling av latency (og i noen tilfeller tidobling) i forhold til det som er teknisk banalt enkelt å få til er per definisjon ikke bra, uavhengig av det faktiske antall millisekunder som brukes.

Ja, PA legger på latency, men det er for at du skal få en bedre brukeropplevelse. Nettopp for å unngå skipping og for å senke strømforbruk.

 

Det er tydelig at du ikke har forstått samspillet mellom PulseAudio og ALSA. Hvis ALSA har 20ms latency og PulseAudio har 20ms blir det ikke mindre skipping enn om man hadde brukt ALSA direkte, for hver buffer er fortsatt 20 ms. Total latency fra progrmmet til høyttalerne blir derimot dobbelt så høy. CPU-forbruket blir heller ikke mindre (ikke at CPU-forbruk bryr meg her).

 

En annen ting er at du ikke har forstått samspiller mellom buffer og latency (hvis det er implementert på rett måte). Bufferen bør være stor på en mediaavspiller, gjerne 10 sekunder. Men med normal latency (30ms) så kan man gå tilbake og overskrive bufferen dersom man vil gjøre endringer raskt (f.eks. pause eller volumendring).

 

Pulseaudio benket til 20ms latency på en galaxy nexus som kjører Android (altså meget svak hardware med betydelig behov for strømsparing):

Igjen så har du ikke tatt med samspillet mellom PulseAudio og ALSA. Hvis ALSA har 20 ms og PulseAudio har 20 ms så blir dette 40 til sammen, noe som faktisk er dårlig mtp at det ikke er en hardware-begrensning. I praksis fremstår heller ikke PulseAudio sånn som standard på et distroer som Ubuntu og Mint.

 

Pulseaudio har dynamisk håndtering av latency, det er for å unngå buffer underrun.

Dynamisk og dynamisk fru blom. PulseAudio øker bufferstørrelse ved underrun, men reduserer den aldri igjen.
Lenke til kommentar

Det er tydelig at du ikke har forstått samspillet mellom PulseAudio og ALSA.

Så vi er nede på dette nivået i diskusjonen? Skjerpings. ALSA er driveren, og den gir en typisk latency på 5ms, så nei, du får ikke 40ms når du legger sammen.

 

En annen ting er at du ikke har forstått samspiller mellom buffer og latency (hvis det er implementert på rett måte). Bufferen bør være stor på en mediaavspiller, gjerne 10 sekunder. Men med normal latency (30ms) så kan man gå tilbake og overskrive bufferen dersom man vil gjøre endringer raskt (f.eks. pause eller volumendring).

Jeg er fristet til å si at denne tråden viser at du ikke har forstått samspillet mellom latency, buffer, ressursbruk og strømforbruk. Hva forsøker du å si her? Pulseaudio gir typisk total latency under 30ms.

 

Jeg sjekket opp skipping. Den ser ut til å ramme noen, og var visstnok knyttet til driveren. Problemene ser ut til å være fikset i de to siste Ubuntu versjonene. Ihvertfall rapporterer mange om at problemene er borte etter oppgradering. Linux forsøker å støtte alt av hardware, at det medfører problemer som man ikke ser på en Mac bør ikke overraske noen.

 

Lenke til kommentar

 

 

Pulseaudio gir typisk total latency under 30ms.
Hvis det er det som er tilfellet på en moderne distro, så skal jeg være veldig fornøyd. :) Men de kalde harde fakta er at når det tar et halvt sekund fra man trykker pause/play til det skjer noe, så er faktisk ikke latency på 30 ms. Når jeg drar volumkontrollen opp og ned og lyden henger etter så er faktisk ikke latency på 30ms. Så enkelt er det bare, og dette har vært et problem for MANGE helt siden introduksjonen av PulseAudio.

 

Du ser det på steam-forumet, folk klager over at de har gigantisk latency. "Jeg fyrer av og skuddlyden høres ikke før missilet treffer veggen 1 sekund senere".

 

 

 

Den ser ut til å ramme noen, og var visstnok knyttet til driveren. Problemene ser ut til å være fikset i de to siste Ubuntu versjonene.
Det har de sagt helt siden PulseAudio kom ut: det rammer bare noen, og det er fikset i siste versjon.
Lenke til kommentar

Jeg starter siste versjon av linux mint xfce fra minnepenn. Jeg gaar inn paa youtube. Fra jeg trykker play eller pause til det skjer noe er det saa lang tid at jeg kan ta frem stoppeklokka og ta tiden. Responstiden er mellom 0.5 sekund og 1 sekund.

 

Saa fyrer jeg opp Totem og justerer volumet i programmet. Mens jeg drar i slideren oppstar det en svak "prikkelyd" og noen "knrt"elyder.

 

Innimellom (uten av jeg gjør noe annet enn å lytte) kommer de samme små korte "knrt" som jeg beskrev over som du påsto var fikset i siste versjon. Nei det er ikke fila, jeg spolte tilbake og hørte igjen.

 

Jeg åpner pulseaudio sin volumkontroll og endrer volumet til totem derfra. Også der prikking og knrt når jeg drar i slideren. Volumendringen henger tydelig etter musa.

 

Vennligst ikke gjenta mer driver ditt og datt, jeg har kjørt dual bootet distroer med og uten pulseaudio på den samme pcen. Driverne er jo de samme, forskjellen er pulseaudio.

 

Etter min standard, så er det for dårlig.

Lenke til kommentar

Jeg starter siste versjon av linux mint xfce fra minnepenn. Jeg gaar inn paa youtube. Fra jeg trykker play eller pause til det skjer noe er det saa lang tid at jeg kan ta frem stoppeklokka og ta tiden. Responstiden er mellom 0.5 sekund og 1 sekund.

 

Saa fyrer jeg opp Totem og justerer volumet i programmet. Mens jeg drar i slideren oppstar det en svak "prikkelyd" og noen "knrt"elyder.

 

Innimellom (uten av jeg gjør noe annet enn å lytte) kommer de samme små korte "knrt" som jeg beskrev over som du påsto var fikset i siste versjon. Nei det er ikke fila, jeg spolte tilbake og hørte igjen.

 

Jeg åpner pulseaudio sin volumkontroll og endrer volumet til totem derfra. Også der prikking og knrt når jeg drar i slideren. Volumendringen henger tydelig etter musa.

 

Vennligst ikke gjenta mer driver ditt og datt, jeg har kjørt dual bootet distroer med og uten pulseaudio på den samme pcen. Driverne er jo de samme, forskjellen er pulseaudio.

 

Etter min standard, så er det for dårlig.

Ja, det er for dårlig. Jeg har aldri observert så dårlig latency. Jeg har umiddelbar respons i youtube og amarok enten jeg bruker volum/pause på applikasjon eller volumkontroll med kmix. Testet på laptop med Debian testing og KDE i dag. Kan aldri huske å oppleve latency i nærheten av halvt sekund på noen linuxboks, og jeg har brukt mange. Fordi PA trigger problemet, så betyr ikke det at problemet ligger i PA. Mange av de problematiske lydkortene har fått fikset driver. Å legge inn work-arounds for hvert lydkort i PA er en slippery slope.

 

Når det gjelder typiske tall, så testet jeg på min laptop med

pacmd list-sinks

fikk under 20ms latency på youtube, men over 30ms på amarok. For spill klaget Ubuntu en tid tilbake, og de refererte da til typisk 25ms latency, ref. http://www.phoronix.com/scan.php?page=news_item&px=MTIxOTg

 

Imidlertidig viser det seg at SDL har funnet god løsning på problemer, og utvikleren selv rapporterer at SDL bør gi god latency for spill:

http://www.phoronix.com/forums/showthread.php?74895-Ubuntu-Desires-Lower-Audio-Latency-For-Gaming&p=294879#post294879

 

Hvis du har mulighet, så sjekk med annet lydkort. Supert om du kan rapportere problemene i en bug tracker.

Lenke til kommentar

 

 

Fordi PA trigger problemet, så betyr ikke det at problemet ligger i PA.
Så vidt jeg husker, så har PA innrømmet at problemet ligger hos dem, fordi algoritmen for å øke bufferstørrelse dynamisk trigges av oppstarten til flash, men PA har ikke kommet så langt at de har implementert dynamisk krymping av bufferstørrelsen. Dette har de så vidt jeg vet heller ingen planer om å gjøre innen uoverskuelig fremtid.

 

Man kan senke bufferstørrelsen manuelt ved å sette PULSE_LATENCY_MSEC=150 før man kjører firefox. Dette gir en latency på 150 ms som såklart er uakseptabelt, men lavere latency gir knrt-lyder, som ihvertfall er uakseptablet. 150ms er uansett mye bedre enn standard.

 

Dette er ikke et skjeldent problem. Hele nettet er oversvømmet av latencyproblemer med pulseaudio uspesifikt og med flash spesifikt.

Lenke til kommentar

Her var det jeg gjorde.

 

1. Lastet ned mint-x-icons_1.1.8.tar.gz herifra.

 

2. Gikk på Application Appearance > Icons > Install Theme File.

 

3. Fungerte ikke. Fikk bare opp «The file is not a valid icon theme archive.»

 

4. Så jeg pakket ut filen, Den var bestående av «Mint-X» og «Mint-X-Dark».

 

5. Dermed gjorde jeg Mint-X og Mint-X-Dark om til en egen .tar.gz-fil hver.

 

6. Deretter prøvde jeg igjen. Mint-X-Dark går ikke an å gjøre om til et eget theme, men Mint-X kan det.

 

Det som er problemet mitt er at ikonene til ikonene på programmene ikke endres. Før og etter.

 

 

 

 

På meg virker det som om du styrer på og utforsker mer eller mindre nyttige ting. Ikke noe i veien for å leke og utforske, det er viktig, men kanskje ikke det lureste å gjøre på samme maskin/installasjon man bruker for produktivt arbeid. Du kan f.eks. ha en egen installasjon eller virtuell maskin for testing og utforsking, og en annen som du kan ty til og stole på når du skal arbeide.

 

Ja takk, skal kjøre det på denne installasjonen.

Endret av Toppitus
Lenke til kommentar

Nå tester jeg dette på linux mint olivia, som ikke er siste versjon, men den jeg har installert.

 

pacmd list-sinks

Jeg tror ikke den infoen har noe med saken å gjøre. En sink er der lyden går ut. Min sink har navnet <alsa_output.pci-0000_00_1b.0.analog-stereo> og en latency rundt 20 ms.

current latency: 19,86 ms

configured latency: 20,00 ms; range is 0,50 .. 371,52 ms

 

Dette er altså dit PulseAudio sender lyden når PA er ferdig med å mikse den. Og er den latencyen man ville ha hatt hvis alle programmene hadde brukt alsa direkte, uten pulseaudio. Det er den latencyen vi vil ha.

 

Problemet med pulseaudio er at man ikke får denne latencyen fordi pulseaudio har sin egen buffer der den mikser alle lydstrømmene først (som sikkert også har sine egne buffere), noe som introduserer ekstra latency.

 

Så uansett om jeg kjører flash med PULSE_LATENCY_MSEC=20 eller 200 eller lar være å sette den og får rundt 500 som er ekstremt merkbart, så viser sinken selvsagt den samme latencyen. For sinken sin latency har med størrelsen på alsa sin buffer å gjøre. Mens PulseAudio sin latency introduseres i miksinga før dette.

 

Sånn var det da jeg satte meg inn i det for en stund siden, og jeg ser ikke noe annerledes nå.

 

Det du må kjøre for å vite den latencyen som PulseAudio har lagt til som jeg klager over må du kjøre pacmd list-sink-inputs, som ser sånn ut for meg:




>>> 1 sink input(s) available.
    index: 2
	driver: <protocol-native.c>
	flags: 
	state: RUNNING
	sink: 0 <alsa_output.pci-0000_00_1b.0.analog-stereo>
	volume: 0: 100% 1: 100%
	        0: 0,00 dB 1: 0,00 dB
	        balance 0,00
	muted: no
*******	current latency: 472,06 ms <- ******************
	requested latency: 20,00 ms
	sample spec: s16le 2ch 44100Hz
	channel map: front-left,front-right
	             Stereo
	resample method: (null)
	module: 8
	client: 28 <ALSA plug-in [operapluginwrapper-native]>
	properties:
		media.name = "ALSA Playback"
		application.name = "ALSA plug-in [operapluginwrapper-native]"
		native-protocol.peer = "UNIX socket client"
		native-protocol.version = "27"
		application.process.id = "3580"
		application.process.user = ""
		application.process.host = "mint"
		application.process.binary = "operapluginwrapper-native"
		window.x11.display = ":0.0"
		application.language = "en_US.UTF-8"
		application.process.machine_id = "2f6a9045c2bc8db6bf32b2d7517969bf"
		module-stream-restore.id = "sink-input-by-application-name:ALSA plug-in [operapluginwrapper-native]"
Og dette er altså i tillegg til alsa sin latency, og sannsynligvis PA sin miksing latency også. Endret av Tåkelur
Lenke til kommentar

Du finner en liste over kjente drivere med problemer her:

http://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/BrokenDrivers/

 

Med din målemetode får jeg også 500ms, men det er bare tull. Jeg har ikke i nærheten av 500ms latency på de operasjonene du testet. Når det gjelder flash som applikasjon, så kan det også hende at det ligger noe grums der. Applikasjonsutviklere må selv ta stilling til hvor mye latency de skal programmere for (med mindre de bruker biblioteker som tar seg av det). ref. http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/LactencyControl/

 

Når det gjelder flash gir jeg meg, jeg klarer å reprodusere lag i lyd ved endring av volum og pause, men med amarok har jeg ingen slik lag. Jeg vil tro dette er kodet inn i flash rett og slett. Hver applikasjon kan sette sin egen latency som du ser i utviklerveiledningen jeg lenket til i forrige avsnitt. Bruk html5 spilleren i youtube på samme klipp så er forsinkelsen borte: http://www.youtube.com/html5

At flash er noe dritt er ikke noe nytt, så hvis det holder deg på windows får du ha lykke til.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...