1 Jun
2007
1 Jun
'07
1:20 p.m.
Pieter Palmers wrote:
Robin Gareus wrote:
I have not dug that deep into ngSpice - but from what I've gathered
every instance can modify the time-step depending on different
conditions for each element during the simulation. - That would be a
reason to implement the audio-sink as element (or model) rather than
'print' command..
ngSpice too interpolates points during a transient analysis, and a 1st
order might be the best one can get anyway.
gnucap might have been the better choice. - When I started, I thought
it'd be a nice /afternoon/ project to fire up SPICE. yawn. - I'll try
upsampling and interpolating input-samples and the reverse on the output
- but else I'm heading back to the drawing board.. and other endeavors.
more later, gotta run now.
robin
Erik de Castro Lopo wrote:
Since you're patching ngspice anyway, maybe introducing a fixed-timestep
behavior into ngspice is easier? IMHO it's the 'correct' solution (cfr
other mails). Robin Gareus wrote:
When Spice loads the libsndfile component, can the component find out
the inter-sample period used by Spice?
no. Spice does not use a constant interval; else it would be straight
forward to use libsamplerate.
If the above is not possible, I suggest that you
up sample the audio
by say 128 times and then linearly interpolate to get whatever inter
sample values you need.
sounds like a great idea.
I should do that with the output too, but it's a little more complex
there: In the beginning I've tried to take the average for all the
"spice"-samples matching the corresponding audio-sample. I've only tried
that up to 1/(4*Fsample) and it gave much worse results than just taking
the closest sample... - combining interpolation and resampling could be
the solution.
now that I've got the framework, I'll dig into the details..