Signifigant delay when using Max Bitrate option IIS/Tomcat
Posted: Tue Dec 14, 2010 2:33 amI have searched and searched the forum and found no mention of this problem.
What is happening is the stream of a song does not start until the system completes the down sample of an MP3 when using the Max Bitrate option. There is a significant delay of 30-35 seconds per song. If I am not using the Max Bitrate option there is no delay. I understand that Lame has to kick in and do the conversion, however using the Jetty version of Subsonic I see that Lame kicks in and the stream starts in a few seconds. Lame continues to convert while the stream continues.
I am using IIS/Jakarta/Tomcat with SSL enabled. Here is what I have tried or observed.
1. Jetty version starts stream quickly even with lower spec hardware.
2. Hitting Tomcat directly and bypassing IIS the stream begins faster then with the Jetty version. (Have to stay with IIS as other sites are served)
3. SSL or non-SSL has no effect.
4. IIS compression (Dynamic or Static) has no effect as expected.
5. After the above I would be incline to say its the IIS/Jakarta combo causing the problem.
6. I am using the 64bit version of Lame but changing version to 64 did shave about 5 seconds off the conversion time.
7. I can see Lame start the conversion in Task mgr and when it finishes the stream begins.
Is anyone else experiencing this? Specifically the IIS/Jakarta/Tomcat users? Anybody have any idea what could be done to speed this up? Its not a server resource question its just that I need to have this working for bandwidth reasons especially for the iPhone and Android users who suffer when a 320+ CBR MP3 is playing.
Please see server specs in my sig, its not a server resource issue though the faster Lame converts the faster the stream will start.
Thanks so much any help you can offer.!
Craig
What is happening is the stream of a song does not start until the system completes the down sample of an MP3 when using the Max Bitrate option. There is a significant delay of 30-35 seconds per song. If I am not using the Max Bitrate option there is no delay. I understand that Lame has to kick in and do the conversion, however using the Jetty version of Subsonic I see that Lame kicks in and the stream starts in a few seconds. Lame continues to convert while the stream continues.
I am using IIS/Jakarta/Tomcat with SSL enabled. Here is what I have tried or observed.
1. Jetty version starts stream quickly even with lower spec hardware.
2. Hitting Tomcat directly and bypassing IIS the stream begins faster then with the Jetty version. (Have to stay with IIS as other sites are served)
3. SSL or non-SSL has no effect.
4. IIS compression (Dynamic or Static) has no effect as expected.
5. After the above I would be incline to say its the IIS/Jakarta combo causing the problem.
6. I am using the 64bit version of Lame but changing version to 64 did shave about 5 seconds off the conversion time.
7. I can see Lame start the conversion in Task mgr and when it finishes the stream begins.
Is anyone else experiencing this? Specifically the IIS/Jakarta/Tomcat users? Anybody have any idea what could be done to speed this up? Its not a server resource question its just that I need to have this working for bandwidth reasons especially for the iPhone and Android users who suffer when a 320+ CBR MP3 is playing.
Please see server specs in my sig, its not a server resource issue though the faster Lame converts the faster the stream will start.
Thanks so much any help you can offer.!
Craig