- Ble medlem
- 26.02.2013
- Innlegg
- 4.772
- Antall liker
- 4.752
@boxman - Bare spekulasjoner og høyttenking. Kan det være du snubler i en bug hvor MQA kan være medskyldig?
Volumio meg bekjent kan ikke gjøre unfold av MQA. Og spiller derfor av lydfilen med den sample rate oppgitt i FLAC containeren, — typisk 16-bit. Kan det være at Tidal connectoren gjør en unfold, — og filen nå muligens blir 24-bit med 6 byes pr stereo sample frame? Og at Volumio enten fortsatt bruker sample rate informasjon fra FLAC containeren eller mer sannsynlig har problemer med å få fylt buffer av årsak nedenfor.
Med stor nok buffer kan ALSA på Linux (som trolig er hva Bladelius kjører) problemfritt switche 16/24-bit audio om 24-bit filen er lagret som 8 bytes pr stereo frame. Men i de tilfellen audio er formatert som S24_3LE* kan det være utfordrene (som i krever ekstra kode) å trimme buffere til dette formatet om man kjører en asynkron buffer mellom de ulike programmene. Ender som regel opp med "hakket" lyd som noen ganger kan bedre seg etter 10-20 sekunder.
En test bruker selv kan forsøke er å velge CD kvalitet og se om "hakking" da blir borte.
*) ARM CPU mest vanlig i denne type produkter
Jeg har ikke gjort noen tester på dette selv, men det virker for meg helt unødvendig å lagre audio som 3 bytes pr sample all tid den skal pakkes med FLAC eller annen lossless koder. Den ekstra tomme byten opptar trolig ikke mye plass etter komprimering, men er en kilde til frustrasjon, feil og problemer.
Volumio meg bekjent kan ikke gjøre unfold av MQA. Og spiller derfor av lydfilen med den sample rate oppgitt i FLAC containeren, — typisk 16-bit. Kan det være at Tidal connectoren gjør en unfold, — og filen nå muligens blir 24-bit med 6 byes pr stereo sample frame? Og at Volumio enten fortsatt bruker sample rate informasjon fra FLAC containeren eller mer sannsynlig har problemer med å få fylt buffer av årsak nedenfor.
Med stor nok buffer kan ALSA på Linux (som trolig er hva Bladelius kjører) problemfritt switche 16/24-bit audio om 24-bit filen er lagret som 8 bytes pr stereo frame. Men i de tilfellen audio er formatert som S24_3LE* kan det være utfordrene (som i krever ekstra kode) å trimme buffere til dette formatet om man kjører en asynkron buffer mellom de ulike programmene. Ender som regel opp med "hakket" lyd som noen ganger kan bedre seg etter 10-20 sekunder.
En test bruker selv kan forsøke er å velge CD kvalitet og se om "hakking" da blir borte.
*) ARM CPU mest vanlig i denne type produkter
Jeg har ikke gjort noen tester på dette selv, men det virker for meg helt unødvendig å lagre audio som 3 bytes pr sample all tid den skal pakkes med FLAC eller annen lossless koder. Den ekstra tomme byten opptar trolig ikke mye plass etter komprimering, men er en kilde til frustrasjon, feil og problemer.
