Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pa-open-stream: Invalid Device #26

Open
benoid opened this issue Dec 6, 2016 · 6 comments
Open

pa-open-stream: Invalid Device #26

benoid opened this issue Dec 6, 2016 · 6 comments

Comments

@benoid
Copy link
Contributor

benoid commented Dec 6, 2016

I've tried to run RSound on a few different Win32 systems, and I've been getting the following error:

\Program Files\Racket\collects\racket\private\kw.rkt:1168:47: pa-open-stream: Invalid device

This error does not seem to occur on Linux or MacOS systems. PortAudio supports Windows, right?

@souravdatta
Copy link
Contributor

I had the same problem and resolved it by changing the frame rate to 44100 from a higher one in Sound settings of the Windows machine. Right click on the sound icon in taskbar and navigate to the advanced properties of the playback device. If the frame rate is selected as something other than 44100, then change it back and restart dr. racket or re run the program.

@benoid
Copy link
Contributor Author

benoid commented Jan 31, 2017

@souravdatta. I can confirm your solution works.

It was also brought to my attention by @Sivat394 yesterday that the (diagnose-sound-playing) procedure specifically produces output requesting the user to change the Windows audio frame rate to 44100. However, I don't currently have access to a Windows machine to check the exact output.

I'm not going to close this issue yet, because I'd like to try to find a solution that doesn't require users to modify any system configurations to run the library. If a fix is not found quickly, it might be worth adding a section to the scribble docs regarding the workaround until the issue is resolved.

Thank you both for your input.

@benoid
Copy link
Contributor Author

benoid commented Jan 31, 2017

The output referenced by the previous comment is located at line 62 of https://github.com/jbclements/RSound/blob/master/rsound/diagnose.rkt.

(define followup-message
  #<<|
If playback at 44100.0 failed and playback at another sample rate
succeeded using Windows 7, you probably need to manually set the 
sample rate of that playback device to 44100 Hz, by right-clicking 
on the volume icon and then digging through menus (properties, advanced).

|
  )

@jbclements
Copy link
Owner

Good news! Well, mostly good news. I've added code to allow users to select a default sample rate (specifically, to choose between 44.1KHz and 48KHz, though it wouldn't be hard to add others to this list). This will allow you to use RSound on Windows systems that have 48K as the default, and is especially useful for those where 48KHz is the only choice.

This solution does have some drawbacks. Specifically, some of the built-in samples are still 44.1KHz, so playing them might cause error messages (the alternative is to translate them on the fly, which might make sense but might not.)

I need to run the tests and publish this code. If someone responds to this message, I can probably get to this today or tomorrow.

@benoid
Copy link
Contributor Author

benoid commented Jan 31, 2017

I just tested setting the default-sample-rate on a Windows machine at one of my university's labs. The result was essentially what you predicted. The 44.1KHz samples do produce error messages even when the RSound default sample rate is set to be the same as the operating system's. Specifically, piano-tone and ding are broken, but synth-note and signal-play begin to work.

@benoid
Copy link
Contributor Author

benoid commented Jan 31, 2017

I think this issue can be closed once those changes are published, but maybe we could open some relevant issues under "enhancement" or "feature" labels For example:

Are there any other 44.1KHz samples? Would it be realistic to synthesize some of these sounds rather than attempt to translate them at run time? That would also overcome the limitation of the finite-length of the samples.

Also, is there any way for RSound to auto-detect the sample rate that the OS is using? I think this would be ideal for anyone who wants to use RSound in applications which are intended to be distributed across multiple platforms.

I can look into either of these, as long as you think they are appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants