Erik de Castro Lopo wrote: All spices I use (although this excludes ngspice) have an option to force them to calculate the response at specified timesteps (along with the ones they need for accuracy). In this case it seems obvious to set this timestep to 1/Fsample. Then use only the values at these timesteps. This is way better than interpolation because the differential equations are actually solved at these points. Greets, Pieter

Pieter Palmers wrote: hehe, right. ATM i don't interpolate at all. The input just stays for the duration of the sample. - there might even be some rounding issues here as ngSpice stores the time in (double) seconds. Can I feed the rabbit at irregular intervals: ie. specify time and sample? So far I've only found the command to set the *maximum* time-step, not an option to enforce it. - setting it to 1/Fsample is ok. setting it to 0.25/Fsample and using only about every 4th value gives much better results.. using 0.01/Fsample makes me fetch a few more coffees; robin

Erik de Castro Lopo wrote: no. Spice does not use a constant interval; else it would be straight forward to use libsamplerate. 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.. robin

Pieter Palmers 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] For guitar distortion, I've found that at 4x oversampling the quality starts to sound bearable, and 8x is what the CAPS units use (with an up- and downsampler FIR filter of 64 taps each). When I started working on virtual amps, this page helped a lot: http://web.archive.org/web/20051128104636/http://www.eecs.umich.edu/~mmccor… It contains a fairly detailed 12ax7 model (the best I found on the net at that time), in a roughly drafted preamp netlist: http://web.archive.org/web/20050905045956/www.eecs.umich.edu/~mmccorq/tubes… My own interest in re-running spice simulations of such circuits is pretty limited (sorry Robin!) but perhaps you may find this interesting. Cheers, Tim

Erik de Castro Lopo wrote: There is a significant difference between the various spice-like tools (hspice, eldo, spectre, pspice, pstar, ...). They all are based upon berkley spice, but that's where it ends... they have evolved. Especially with respect to solution algorithms and options they can differ a lot. I can't really comment on the fact that the problem is the generation of the input signal. Although... (see later) The non-linear nature of the circuit doesn't matter that much. In transient simulations there is no circuit linearization performed, it simulates the nonlinear behavior pretty good. When solving the differential equations they can be linearized, but that shouldn't affect the results in a well-designed and well-configured algorithm. Increasing the sample rate will of course help, but that is actually a side effect, and doesn't guarantee you better results. It won't increase the accuracy of the differential equation solution itself. It just forces a smaller timestep. The better way is to have the simulator choose the points it needs to achieve a certain (predefined) accuracy. After all it is designed to choose them in a sane manner. In order to combat the (re-)sampling issues, you ask the simulator to also solve the equations in the discrete sample points you need, such that you have the "exact" results in these points. This procedure comes down to asking the simulator to simulate a circuit with a certain accuracy (both time- as value-wise) and additionally having it generate the values for the timepoints you need. Regarding the input signal: What I would expect is that if you are able to specify the time points that have to be calculated, and if the input samples are used to calculate these timepoints, it should work rather good. The only thing the intermediate values are used for is the calculation of the derivatives, and some intermediate points that are discarded anyway. One could argue that their value doesn't really matter that much as long as the input value at a timepoint that is retained in the output is correct. Probably a first-order hold (i.e. linear interpolation) will already do fine. Greets, Pieter