Newsgroup: it.comp.musica
Titolo: NUOVA WORKSTATION CON AMD

Ciao a tutti, ho acquistato pc configurato tipo server...la cui
architettura è fondamentalmente formata da due processori athlon 64
2004+, 1 gb ram...ho lavorato precedentemente con un p4 2800 e un amd
64 3000...ho provato questo ma la quantità di plugins che ho aperto
prima di farlo crollare non mi ha entusiasmato più di tanto...diciamo
nelll'ordine dei 20-30 in più...che ne pensate?....posso migliorarlo
di tanto...o no?....lo butto?....
Grazie...

 ha
scritto:

L'unico vantaggio che si ha da una macchina multiprocessore è nella gestione
dei processi multipli. Ma purtroppo i VST sono quasi sempre thread di uno
stesso processo (i così detti LWP). Del resto anche ASIO (tanto veloce
quanto debole) si basa sul principio del "fate finta che il pc non abbia la
scheda audio" per funzionare a latenze dignitose.
L'architettura directX, invece, sfrutta una strategia grossolanamente
client/server (detta gergalmente COM+), che da un lato è più lenta (rispetto
agli LWP) per via della gestione dei contesti di run-time (che nei thread
praticamente non c'è cambio di contesto), ma dall'altro consente maggiore
scalabilità (probabilmente più teorica che pratica) su più processori.
Pertanto, sic stantibus rebus, direi che se ti aspettavi un raddoppio dei
plug-ins utilizzabili sarai decisamente rimasto deluso.
;-)
Quello che, invece, migliora decisamente è la gestione di più programmi
contemporanei (magari più istanze del medesimo host vst ...), peccato che
quasi sempre il primo a partire mette il device in lock.
Il problema è sempre lo stesso, e lo dico da anni: Windows (nelle versioni
desktop) è fatto principalmente per andare su internet. Quando metteranno il
supporto ASIO/VST anche su internet explorer allora le applicazioni audio
andranno alla velocità che ci auspicheremmo tutti leggendo i gigahertz di
targa dei processori.
Ciao, Sandro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 nelll'ordine dei 20-30 in più...che ne pensate?
Se capisco di cosa si tratta - dovendo però ricorrere all'intuito visto 
che le tue indicazioni sono poco precise - non puoi certo pretendere la 
luna da quella macchina. Potrebbe trattarsi di Athlon MP funzionanti a 
1666 Mhz, e non certo di Athlon 64, questi ultimi sono utilizzabili solo 
singolarmente.
Se ci ho preso (nel caso spero che tu abbia rilevato la "baracca" per 
pochi euro) è un sistema a dir poco datato, non in grado di competere 
che le macchine attuali ma non necessariamente da buttare via. 
Controlla, con il Task Manager, che entrambe le cpu vengano sfruttate.
Ciao
Flavio
-- 
Qualche immagine: 
http://www.webalice.it/fl.masi/

 quasi sempre il primo a partire mette il device in lock.
"Siamo" insomma in un vicolo cieco o possiamo attenderci che i sistemi 
dual core, che monopolizzeranno il mercato prossimo venturo, vengano 
sfruttati a dovere, in un futuro non troppo remoto, anche in ambito audio?


 quasi sempre il primo a partire mette il device in lock.
È l'host che deve gestire i processi indirizzandoli su due processori, 
dunque occorre che il kernel audio sia scritto per funzionare (anche) in 
multithreading.
Sonar lo fa abbastanza bene. Non so Cubase, non lo uso. 

 multithreading.
Il kernel di Windows č fortemente multi-threading oriented. Non č questo il
problema. E' lo scheduler di basso livello che "vede" i thread appartenenti
al medesimo processo padre, e dunque non li splitta su piů processori.
Questo č, almeno, ciň che accade sul mio pc WinXP SP2. Forse (e me lo
auguro) sulle piattaforme server la questione č differente.
La gestione del multi-processing č basata sul concetto di "contesto", cosa
che per natura non esiste nei thread (non nel senso tradizionale, almeno
...). Insomma, bisogna rimboccarsi le maniche e mettersi a riscrivere un
pezzo di kernel perchč il multi-threading benefici del multiprocessore.
E c'č dell'altro. Non basterebbe neanche questo a garantire il corretto
funzionamento dell'audio in ambiente multi proc e thread. Occorrerebbe, cosa
ben piů grave, consentire ad un processo di fare "piantare" una macchina,
cioč di farla "alluppare" per il semplice fatto che si č alluppato il
programma.
Sembra una stronzata, ma la cosa implica che un processo puň impossessarsi
in toto di un processore (schedulazione pre-emptiva, tipica dei sistemi
real-time ...), senza accettare interrupt e trap fastidiose, senza applicare
daisy-chain del cacchio assolutamente inutili all'audio. Insomma, a conti
fatti occorrerebbe riscrivere il dos, con supporto multi processo, multi
thread e multi processore.
O passi a Linux, che potrebbe cavalcare (finalmente) l'onda del kernel
moderno e spiazzare la concorrenza dei so che tutto fanno, fuorchč far
funzionare l'audio professionale.
Mi piacerebbe sentire il parere di qualche utente mac in proposito. Hey
Tram, ci sei???


 processore).
Non so, non sono in grado di entrare così nel merito della questione, anche 
se è ovvio che, in qualsiasi modo, un'applicazione deve appoggiarsi al 
kernel di sistema per lavorare a basso livello.
Tuttavia, quello che ti posso assicurare e che puoi anche verificare di 
persona, è che, selezionando l'opzione per far lavorare Sonar in modalità 
Dual Engine, le prestazioni raddoppiano o quasi (se non proprio doppie, 
migliorano dell'80-90%).
Credo che, in qualche modo, Sonar allochi metà delle risorse per la gestione 
dei buffer audio (ridurre la latenza rimane ancora il fattore più critico e 
mangia risorse, per come stanno le cose in ambito Windows) e l'altro per la 
gestione dei processi di sequencing, rendering e processing audio (quindi 
VST, DX. VSTi e DXi).
Sono tutte supposizioni empiriche, poiché, come ripeto, non sono al corrente 
di come stiano davvero le cose, tuttavia, lavorandoci, mi è sembrato che le 
cose stiano più o meno così. 

 cose stiano più o meno così.
Con Windows le uniche considerazioni che si possono fare sono solo empiriche
;-)


 Tram, ci sei???
Ci sono, ma inebetito da tutte le cose tecniche che scrivete. Mi sento
come il bambino di fronte al meraviglioso spettacolo del mondo!
Tutto quel che so è che a livello teorico OS X supporta il
multithreading e il multiprocessing, purché si faccia uso dell'Hardware
Abstraction Layer (Audio HAL):
http://developer.apple.com/audio/coreaudio.html
La gestione degli eventi realtime avviene a livello di CoreAudio, che è
sopra il kernel ma opera a livello molto basso. Probabilmente è proprio
quel pezzo di kernel che auspichi per passare dal multi-threading al
multiprocessore.
Le versioni riadattate di software preesistente (ad esempio, Digital
Performer, Peak, Deck) fanno pieno uso di questa tecnologia, e sono
pienamente multiprocessore (entrambi i processori considerati
pariteticamente).
Logic ha invece adottato una strategia differente, e separa le funzioni
audio (inviate ad un processore) e midi/grafiche, riservate all'altro.
Sull'efficacia e la validità tecnica delle soluzioni adottate non saprei
dire. Mi riservo di approdfondire.
Ciao,
Paolo