Problems with running VM in terminal (Windows 7 64-bit)
Hello all! I am having a strange problem on my desktop PC running Windows 7 Professional 64-bit. I have the chuck.exe binary installed for both the Windows cmd prompt (Windows/System32 folder) and for Cygwin, and it works directly (i.e. chuck foo.ck). However, when I start the VM using chuck --loop, I can't seem to add any shreds to the VM. It doesn't throw an error message or anything, and it appears to start as it should, it just doesn't seem to be listening to any input that I throw at it. I type "chuck + foo.ck" and there is no error message and no output in the terminal that is running "chuck --loop". The same error occurs in both Cygwin and in the basic Windows command-line programs. I have everything working fine (having followed the same exact steps) on my laptop running Windows 7 Home Premium 64-bit, and everything works fine (with some Jack finagling) on my Linux partition on both machines, but I'd like to be able to work in Windows on my desktop, as that is where I spend the bulk of my time for now. Thanks for any advice!
Hey, all. I didn't get any replies the first time around so I'm trying again!
Update:
I now have a discrete sound card (Asus Xonar) and I reinstalled Windows 7 Pro 64-bit from scratch.
I installed the chuck.exe in the System32 folder. It works from the command line as it should now (I get accurate textual output from the program), but I'm not getting any sound at all now. It has full permissions on the system and I'm running as administrator. I have no sound problems otherwise, and miniAudicle is working fine (it produces sound).
Does anyone have any suggestions on how to go about fixing this issue?
Here's some of the output from chuck -v --loop that I think may be relevant:
| devices adc: 0 dac: 0 (default 0)
| initializing 'real-time' audio...
| RtApiDs: callback thread error...
| (RtApiDs: Unable to lock buffer during playback (Primary Sound Driver): Invalid parameter...)
Perhaps it has something to do with real-time audio? Everything worked without a hitch on my W7 Home Premium 64-bit laptop, and I certainly have better audio capabilities on my desktop. If it would be helpful to provide the full output, I can, I just haven't gotten around to installing a terminal with cut/paste functionality yet! My main priority before all else is to get a command-line version of ChucK working as it should!
________________________________
From: [chriswicks]
On Wed, Apr 25, 2012 at 09:21:01AM -0700, [chriswicks] wrote:
Hey, all. I didn't get any replies the first time around so I'm trying again!
Yes, I remember. I'd like to help you, but the last Windows I ran was XP and Cygwin I never tried. That makes it a bit hard to help; certainly not ignoring you. Kas.
Long time i don't use windows too, but i do heard about a "chuck-asio"
maybe it might help you somehow.
Sorry for such "abstract" response haha
On 25 April 2012 17:40, Kassen
On Wed, Apr 25, 2012 at 09:21:01AM -0700, [chriswicks] wrote:
Hey, all. I didn't get any replies the first time around so I'm trying again!
Yes, I remember. I'd like to help you, but the last Windows I ran was XP and Cygwin I never tried. That makes it a bit hard to help; certainly not ignoring you.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Wed, Apr 25, 2012 at 07:02:05PM +0100, henrique matias wrote:
Long time i don't use windows too, but i do heard about a "chuck-asio" maybe it might help you somehow.
It seemed to me that this issue is somehow related to communication between processes (particularly CLI windows). I can't imagine that that's no longer possible as it's quite important for a lot of stuff like server administration. Could it be a firewall issue? The communication between the VM and and the otf commands (like adding a shred) happens through ports on local-host a firewall might mistakenly assume that that is something it needs to stop? Just guessing, Kas.
Hey Chris,
Hmm, if miniAudicle works then conceivably chuck.exe should also work just
as well; they both use the same code to access the underlying soundcard,
but they use slightly different configuration logic by default.
To that end, can you post the output of chuck --probe, and the console
output from miniAudicle after starting the virtual machine?
As far as a proper terminal, Console2 is pretty much the second thing I
install on a new Windows system, after Chrome/Firefox. Highly recommended!
spencer
On Wed, Apr 25, 2012 at 6:14 PM, Kassen
On Wed, Apr 25, 2012 at 07:02:05PM +0100, henrique matias wrote:
Long time i don't use windows too, but i do heard about a "chuck-asio" maybe it might help you somehow.
It seemed to me that this issue is somehow related to communication between processes (particularly CLI windows). I can't imagine that that's no longer possible as it's quite important for a lot of stuff like server administration.
Could it be a firewall issue? The communication between the VM and and the otf commands (like adding a shred) happens through ports on local-host a firewall might mistakenly assume that that is something it needs to stop?
Just guessing, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Well, I have the problem fixed (sort of). The new sound card seems to have been the culprit. For whatever reason, ChucK did not like my sound card. I did a fresh install of Linux while I was at it and had the same issues as I was having in Windows (never had a problem with ChucK in Linux before..I had purchased the sound card to try to resolve Windows issues!). All audio, aside from ChucK audio, was working fine. I took the sound card out and ChucK is working better than ever in both Windows and Linux. Go figure.
________________________________
From: Spencer Salazar
Long time i don't use windows too, but i do heard about a "chuck-asio" maybe it might help you somehow.
It seemed to me that this issue is somehow related to communication between processes (particularly CLI windows). I can't imagine that that's no longer possible as it's quite important for a lot of stuff like server administration.
Could it be a firewall issue? The communication between the VM and and the otf commands (like adding a shred) happens through ports on local-host a firewall might mistakenly assume that that is something it needs to stop?
Just guessing,
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Wed, Apr 25, 2012 at 01:24:05PM -0700, [chriswicks] wrote:
Well, I have the problem fixed (sort of). The new sound card seems to have been the culprit. For whatever reason, ChucK did not like my sound card. I did a fresh install of Linux while I was at it and had the same issues as I was having in Windows (never had a problem with ChucK in Linux before..I had purchased the sound card to try to resolve Windows issues!). All audio, aside from ChucK audio, was working fine. I took the sound card out and ChucK is working better than ever in both Windows and Linux. Go figure.
Great! The state of Linux drivers has generally been improving in the past few years, I think largely thanks to standardised devices, but that's not much help if you want it on Windows :-). It's still odd that the one card wouldn't work. You mentioned running as Admin, is that because you like to or is that needed? If it is needed that should probably be in the docs. Personally I don't think that is a very good sollution, but at least it is a sollution. Congratulations, Kas.
participants (4)
-
[chriswicks] -
henrique matias -
Kassen -
Spencer Salazar