if you mean what you said then the answer is "no", because a buffer always has the samplingrate of the patcher and runtime it is in.

changing samplerate within one signal chain will mean to "stretch" the sample. the basi strategy is to upsample something like *10 or *16 and then downsample again and interpolate a bit.

a lowpassfilter is optional.

poly~ does it all in realtime since max 6... but as you know, only with multiples of 2. 44.1 to 32 is a bit mor ecomplicated if you want perfect sound. i would not do it in max/msp...

Hey Roman,

I don't want to do that in realtime, more like processing a buffer. I don't think it depends on the environment, it's just a property of the loaded soundfile.

a property of the soundfile which is, if i am not mistaken, ignored when loading the file, unless you can convert the samplerate on-the-fly (like you can "import" mp3 to sfplay for example)

and if you´d change the header of the soundfile - that is of course possible - the audio would change its pitch, which is no what you are looking for ;)

buffer~ always adopt the sr of the loaded file, I think the playback objects do the conversion on the fly to fit the environment.

I could convert in java if I could figure out a way to get a proper audio input stream from the float array of the buffer?

java sounds doable, there should be vast libraries for stuff like that, maybe even with antialiasing. but java is not my world and so i am clueless. you can still use sfinfo~ with it to find out if and what conversion is required.

Almost OT, but here is a website with some interesting sample-rate-conversion comparison results of different software from open-source to commercial, including matlab, fscape (which is java-based) and others. You may get some inspiration here.