search

Copinmalin / squeezelite

Automatically exported from code.google.com/p/squeezelite
Other
0 stars 0 forks source link

Switching bitrates mixed with system sounds mismatch #11

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Play a song A at rate X (say 44 kHz)
2. Play system sound (like the beep of a volume change)
3. Play a new song B of a different rate Y (say 96 kHz)

What is the expected output? What do you see instead?
Normal play, but song B is played at the speed X (in this example: high pitch, 
donald duck voice).

To get sound working again:
4. Play song A again (sounds far too low)
5. Play song B again (sounds allright).

From this point I can play anything at any rate, as long as no system sounds 
are mixed in.

What version of the product are you using? On what operating system?
Squeezelite v0.9beta11
Compiled myself from source (64 bit)

Mac mini, OS X 10.7.5 (Lion)

Please provide any additional information below.
No external DAC, only system audio.
Portaudio (pa_stable_v19_20111121) might be the cause.

Original issue reported on code.google.com by mark.r...@gmail.com on 31 Jan 2013 at 9:20

GoogleCodeExporter commented 9 years ago 
After some more testing, I've come to the conclusion that the system sound mix 
does not affect the problem. It is just that after a switch to a song of a 
different bitrate, it often gets played at the speed of the previous song. So 
after a switch, sometimes it is played at the proper speed, sometimes not (in 
which case I switch twice, and repeat that until it gets played okay).

Original comment by mark.r...@gmail.com on 31 Jan 2013 at 9:38

GoogleCodeExporter commented 9 years ago 
Debug log attached:
- started squeezelite
- played song at 96 khz ok
- played song at 44 khz wrong (sounds low, slow)
- played song at 96 khz ok
- played song at 44 khz ok

Original comment by mark.r...@gmail.com on 31 Jan 2013 at 9:42

Attachments:

GoogleCodeExporter commented 9 years ago 
I don't get this on 10.6 - could you try updating to the latest svn version of 
portaudio which is the version I am using.

Original comment by trio...@btinternet.com on 2 Feb 2013 at 6:20

GoogleCodeExporter commented 9 years ago 
I just downloaded the binary you compiled 
(http://code.google.com/p/squeezelite/downloads/detail?name=squeezelite-osx&can=
2&q=), version 1.0rc1 and this shows the same behaviour.

Also checking out PortAudio and building against the svn version does not make 
a difference.

BTW, I created a clone of this project and made two commits you might want to 
pull (just cosmetic changes).

Original comment by mark.r...@gmail.com on 3 Feb 2013 at 10:19

GoogleCodeExporter commented 9 years ago 
Commenting out:

#if OSX
        // enable pro mode which aims to avoid resampling if possible
        PaMacCoreStreamInfo macInfo;
        PaMacCore_SetupStreamInfo(&macInfo, paMacCorePro);
        outputParameters.hostApiSpecificStreamInfo = &macInfo;
#endif

fixes the issue. I'll try to find a better fix.

Original comment by mark.r...@gmail.com on 3 Feb 2013 at 10:36

GoogleCodeExporter commented 9 years ago 
Hum - that was need by me to get it to set the output at the sample rate of the 
track rather than resample everything....  

I suspect this means it pa version specific.  Did you manage to try with the 
latest svn version of portaudio?

Original comment by trio...@btinternet.com on 3 Feb 2013 at 10:45

GoogleCodeExporter commented 9 years ago 
It seems to be a Portaudio bug indeed. Yes, I build against the latest 
Portaudio Subversion release (trunk). Your 1.0rc1 build suffers from the 
problem too.

So far I found just a single report of the same issue: 
http://music.columbia.edu/pipermail/portaudio/2009-June/009189.html, with no 
usable reply from Portaudio guy Bjorn.

$ squeezelite-osx -l
Output devices:
  0 - Built-in Input
  1 - Built-in Output
  2 - Plantronics .Audio 400 DSP

It seems that the failure to correctly switch sample rates only affects the 
build-in Mac output (id #1). When I select an USB headset with it's own DSP 
(Plantronics .Audio 400 DSP, terrible headset btw), also in paMacCorePro mode,  
I can switch songs with different sample rate as often as I want to. This could 
be the setup for a work-around kludge.

Original comment by mark.r...@gmail.com on 3 Feb 2013 at 10:57

GoogleCodeExporter commented 9 years ago 
That may explain what I see as I did my testing with an external usb dac.

Do you recommend we change the squeezelite code for the moment or look to find 
a patch to PA which works?  I'd really like to force sample rate changing to 
match the track as people with external dacs are unlikely to want everything 
resampled..

Original comment by trio...@btinternet.com on 3 Feb 2013 at 11:03

GoogleCodeExporter commented 9 years ago 
Can you reproduce my problem for build-in output? That is, switching between 
songs of different sample rate plays the song at the wrong speed in about half 
of the cases?

I've committed a patch to fix the issue in the form of a workaround. In case of 
build-in output, paMacCorePlayNice will be used instead of paMacCorePro. You 
can pull the code from 
http://code.google.com/r/markruys-squeezelite/source/list.

Original comment by mark.r...@gmail.com on 3 Feb 2013 at 11:58

GoogleCodeExporter commented 9 years ago 
I don't seem to be able to reproduce this on 10.6.8.  It seems to change 
frequency accurately for the built in audio.  Could this be because you have 
other applications also opening the internal device?

I do get some errors about bad format for 192k, but it does not impact the 
playback frequency:
||PaMacCore (AUHAL)|| Error on line 406: err=''!dat'', msg=Audio Device: 
Unsupported Format
However it then goes on to play.

Thanks for finding the use of the wrong enum constants - will fix that.

I think forcing the internal device to allow resample may be a good idea though 
- let me consider the patch for inclusion.

Original comment by trio...@btinternet.com on 3 Feb 2013 at 12:46

GoogleCodeExporter commented 9 years ago 
Did the latest version fix this for you?

Original comment by trio...@btinternet.com on 10 Feb 2013 at 5:44

GoogleCodeExporter commented 9 years ago 
Yes it did. Although kind of work-around, I guess that's the best shot. 
Probably it has something to do with Portaudio not working nicely with Lion. As 
I understood, in Lion there were some big changes in audio handling.

Ticket can be closed as solved.

Original comment by mark.r...@gmail.com on 11 Feb 2013 at 8:57

GoogleCodeExporter commented 9 years ago 
Closed as verified workaround in place

Original comment by trio...@btinternet.com on 11 Feb 2013 at 9:23