Newsgroup: it.comp.os.linux.sys
Titolo: [AUDIO crapping] perchè gli mp3 gracchiano?

Dopo aver sperimentato su me stesso ;-)
e dopo aver letto diversi post sull'argomento,
voglio illustrarvi cosa la mia testolina buggata ha dedotto
e reso disponibile a falsificazione:
Più volte qualcuno si è lamentato di mp3 che gracchiano nonostante la
scheda sia configurata e funzionante:
a) problema di IRQ?
   Qualcuno ha avanzato questa ipotesi, vista la possibilità di avere
IRQ condivisi sotto linux.
b) Framebuffer Device fallace
   Questa la avanzo io:
 Il fatto che il problema si presenti "con questa distribuzione si' e
con quella no" o "solo quando uso Netscape" o se uso "XFree 4 con XXXX
opzione attivata" secondo me indica che sarebbe opportuno provare a
disabilitare nel kernel il "framebuffer device support" o al massimo
usare quello standard per tutte quelle conformi VBE 2.0.
Nel mio caso ho notato che usando un vesafb patchato per usare il
framebuffer lineare sulle S3 (la mia VBE 1.2) porta problemi quando
ascolto un mp3 e faccio scrollare moltissimo testo su xterm o faccio
scivolare una paginona sul Communicator (uso il 4.76).
Non so per quale motivo, ma nelle altre situazioni tutto sembra
regolare, come se si introducesse una latenza strana da qualche parte
nel kernel che si rende manifesta solo in certe situazioni.

 usare quello standard per tutte quelle conformi VBE 2.0.
anche a me il frame buffer, in alcune occasioni, da' problemi...
solitamente fila tutto liscio come l'olio, ma in alcuni casi sembra
andare in crisi. Basta leggere una man page, andare un po'
in giu' e poi tornare all'inizio della pagina con il tasto '<'.
Lo scrolling e' lentissimo (da me impiega circa 3 secondi per
ridisegnare una schermata da 36 righe!) e il sistema e' talmente
sotto carico da far saltare il lettore di mp3 (o da sputtanarmi una
masterizzazione, grunt :/).
il tutto su un k7@550 con una riva tnt2 ultra, kernel 2.4.1 con
framebuffer nvidia, risoluzione 768x576-8@100 (virtual-yres 2880)
-- 
addio, e grazie per tutto il pesce

 framebuffer nvidia, risoluzione 768x576-8@100 (virtual-yres 2880)
        Guarda io ho praticamente la stessa configurazione e pure a me il 
framebuffer scassava parecchio (leggere le man pages era un'agonia).    
        Ho risolto (o quantomeno migliorato di molto) diminuendo la 
profondita' di colore a 8bit (256 colori). Prima la utilizzavo a 
32bit. La risoluzione e' sempre la stessa, 1024x768.
        Ciao, Giovanni.
-- 
   |^^^^|
   |    |  Eat my shorts !             * Linux Powered *
   |()()| /                            - Kernel 2.2.18 -
                 -> gio.bcc(at)
tin.it
 <-

32bit. La risoluzione e' sempre la stessa, 1024x768.
Quindi le cose cambiano parecchio a seconda dell'adattamento di vesafb
che si sta usando, muble...
Opinioni e esperienze da chi usa vesafb (non matroxfb, ecc)??
Io dubito che il mio sia un problema di volume, perchè il "rumorino"
si lega sempre a un evento di scrolling in una finestra di X, che sia
xterm o netscape, quindi non si parla di una applicazione che non va
ma di una serie di sfortunate coincidenze che fanno manifestare questo
spiacevole effetto...
dimenticavo, ho una scheda audio opti931 ISA, una S3 (325) e uso XFree
4.0.2 con un kernel 2.2.18

spiacevole effetto...
Dentro X non ci sono problemi a casa mia.
Hmmm. Hai provato anche X3 ? E se carichi il minimo possibile di moduli di X ?
-- 
	Giuseppe "Cowo" Corbelli  -->>  Riding on Linux-2.2.16
        **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
 [cowo@braveheart cowo]$ make sex
    make: *** No rule to make target 'sex'.  Stop. 
        :-((((

Hmmm. Hai provato anche X3 ? E se carichi il minimo possibile di moduli di X ?
X3 non lo provero', mi sembra assurdo dover tornare cosi' indietro, ma
per quel che ricordo non avevo problemi di questo tipo. Ho contattato
l'autore delle ultime versioni del driver per s3virge e vedremo cosa
salterà fuori, sempre che ci sia veramente qualcosa che non va.

salterà fuori, sempre che ci sia veramente qualcosa che non va.
C'e' di sicuro qualcosa che non va. Dicevo di X perche' in console con
framebuffer sorgono occasionali problemi. Visto che per te ci sono casini
anche in X...
Non potrebbe essere qc a livello di driver audio?
--
  	Giuseppe "Cowo" Corbelli  -->>  Riding on Linux-2.2.16
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Computers are not intelligent.  They only think they are. !>-

Non potrebbe essere qc a livello di driver audio?
Ho comprato una yamaha opl3-sax e una matrox mystique e ancora noto
qualche stranezza mentre riproduco un mp3 con mpg123 lanciato in una
finestra xterm:
ls -all -R sulla root dà una specie di singulto all'inizio dopodichè
tutto sembra normale
scrollare una pagina col Nescape 4.76 invece dà sempre un quasi
impercettibile "zompettare"
ho provato ad usare vesa e fbdev al posto di mga e come per magia
nessun problema.
A questo punto mi viene da pensare che il problema sia semplicemente
il modo in cui viene sfruttato il bus PCI: non mi sembrava di aver
usato opzioni molto aggressive, ma evidentemente XAA di default è
troppo aggressiva per il mio BIOS oppure questo non è proprio
compliant oppure il bridge PCI-ISA è stato progettato molto male.

 ha scritto:

Hai pensato di lanciare mpg123 con l'opzione -b 1024 per dargli un po' di
buffer?
comunque e' una cosa "normale", con i chip Maestro succede di peggio... il
gracchiare aumenta fino a che non stoppi l'audio per 5/6 secondi finche' non
hai svuotato i buffer del dsp... a detta degli sviluppatori, sono i chip
audio che sono molto scarsi, sono di qualita' scarsa e molte delle funzioni
che hanno sono "fake", per esempio nel chip maestro ci sono documentate delle
funzioni di DMA che poi pero' una volta su tre non funzionano... e quindi di
solito l'atteggiamento e': se devo scegliere se piantare l'OS o far
gracchiare il chip... l'unica e' evitare chipset economici come gli ess e gli
Yamaha, certo se hai un laptop ti attacchi
ciao ciao ciao
-- 
Marco Ermini
http://www.markoer.org
 - ICQ # 50825709
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.      -- Jeremy S. Anderson