@moghetto: Are you using USB-C port to connect the keyboard? As far as I can see, all USB-C ports in Macmini 2018 are wired through Thunderbolt controller. Thunderbolt will not work under wrfplay-live, and that would mean that none of those USB-C ports will work. Also, the spec lists two USB-A ports. These may be wired to XHCI controller. If this is the case they should work.
NB, USB ports in Macmini 2013 are wired to HXCI controller.
NB, USB ports in Macmini 2013 are wired to HXCI controller.
Hi, thanks for reply. I still have to find and so, test, a wired keyboard, Yes, when I'll get the wired keyboaed, it will be connected to the USB/A port, anyway I still don't understand why my magic keyboard works with the old macmini and not with the "new" one...I'll let you know as soon I'll try a wired keyboard..
Thank you again..
Thank you again..
IIUC the new macmini has the USB ports you use provided by thunderbolt which as @frd__ says is not supported by the wtfplay kernel. Whereas the old macmini uses a standard xHCI USB controller which has been supported by linux for decades. Testing the wired USB keyboard will tell more.
Sorry, may be I haven't understood,...My apple magic keyboard is wireless and works fine with the old mac mini... not with the new one. Even if a wired keyboard will work with the new macmini, a wireless keyboard (apple or not) will not ?
The first step is finding some way to communicate with your device. I am not sure you can do any troubleshooting wtfplay without a working keyboard, whether is runs some network access server like ssh etc.
If the USB controller in the new macmini is not supported, no USB device will work, logically.
If the USB controller in the new macmini is not supported, no USB device will work, logically.
Good evening everyone, Tried a wired usb keyboard and works ok. I still don't understand why the wireless keyboard works on the 2011 macmini but not with the 2018...
OK, good. At least now you have a control over the computer. I am guessing that you are using USB-A ports to connect the keyboard. This also means that they are indeed wired to xHCI controller.
Regarding the wireless keyboard of yours: does this keyboard come with some sort USB dongle that you need to plug into USB port to get it working? I read that Apple keyboards can also use USB-C cable and Bluetooth. Well, Bluetooth will not work with wtfplay-live (no BT drivers in the system). TBH, I am not familiar with Apple device ecosystem at all.
Regarding the wireless keyboard of yours: does this keyboard come with some sort USB dongle that you need to plug into USB port to get it working? I read that Apple keyboards can also use USB-C cable and Bluetooth. Well, Bluetooth will not work with wtfplay-live (no BT drivers in the system). TBH, I am not familiar with Apple device ecosystem at all.
Mi apple wireless keyboard doesn't have any cable to conect to the macmini, it is just wireless...May be the MAcos system can do the difference ? On the 2011 with "mountain lion" works, on the 2018 with "sequoia" doesn't. Anyway many thanks for your help..
Dear @frd__ , i am running new box and bios cpu freq setting is not available. Still wtfplay is going slowly, does it has an ability to set cpu freq? Seems intel cpu power driver is not loaded. Does cpu freq can affect audio performance in your opinion? I am trying to go fanless so need less heat.
Hi @promisc, Thanks and Happy New Year for you too!
Playing synchronously with two devices would not be a trivial task. As you pointed out - the two devices would need to be synchronized very closely. Ideally a given audio sample is processed by the DAC chips in the two devices exactly at the same time. A much easier thing to do would be to employ 4 or 6 channel DAC and change wtfplay to use that.
I am afraid I may not have time to look at wtfplay anytime soon. I am trying to finish my AD1865 DAC build, components of which sit on my desk for a long time now. Sometimes I feel ashamed that it is still not finished yet 😉
Playing synchronously with two devices would not be a trivial task. As you pointed out - the two devices would need to be synchronized very closely. Ideally a given audio sample is processed by the DAC chips in the two devices exactly at the same time. A much easier thing to do would be to employ 4 or 6 channel DAC and change wtfplay to use that.
I am afraid I may not have time to look at wtfplay anytime soon. I am trying to finish my AD1865 DAC build, components of which sit on my desk for a long time now. Sometimes I feel ashamed that it is still not finished yet 😉
Dear @frd__ , this is actually the reason of my prev post. I just recieved an R2R NOS DAC fiio k11, via tube preamp it sounds quite interesting, different from delta-sigma. So the idea to mix dacs and speakers to take advantages of both. I believe two dacs can be synced with once step response measurement and will be const like -d hw:1 -d hw:2 --delay 5ms . Hope you finish your R2R project soon, and think about it again. Thanks
Merging dacs clocks not necessary, just output delay correction with phase measurement. Not an untrivial task, am i right?
This only helps for syncing the start of playback. The DACs have individual clocks that run at slightly different speeds, so they will slowly drift apart while playing. After a few tracks, they may be milliseconds apart.
I am trying to imagine how this measurement can be done. Do you have any particular setup in mind?
In my simple view one would need to record the timestamp when software starts triggers the playback (say ALSA PCM is started) and another timestamp when a measurement device detects the analogue waveform at the output of the DAC. That means the clock on the playback computer and the measurement device need to be very precisely synchronised (PTP maybe?). And what would be the acceptable measurement error level? Half of the audio frame (e.g., 11.2usec for 44.1 kHz sampling rate)?
@frd__ I believe simple mic with REW software and two identical speakers on same channel on different dacs standing next to each other can give some information. I will try to check. Please keep in mind non phaselinear speakers already have delays between channels and this delays can be measured with just mic.
@HenrikEnquist seems wtfplay kill the process every song, so relative delay will be restored... (?)
@HenrikEnquist seems wtfplay kill the process every song, so relative delay will be restored... (?)