Interacting with a mycroft
Frederyk, Cześć!
I am soon to try your system on an old computer for playing on a frugalhorn mark 3.
I had the thought today of possibly trying to write a mycroft skill to control wtfplay remotely. It seemed to me that this would preserve the elegance of your system, and what I assume to be it's lack of jitter because the entire computer is only dedicated to playing audio, while gaining an intuitive (voice-controlled) interface running remotely on a seperate device (a mycroft).
However, of-course, the mycroft on a separate device would somehow have to communicate with wtfplay. Do you recommend one of the following approaches (or another I haven't thought of)? My thoughts were:
1. Direct Ethernet cable from mycroft to wtfplay machine, only passing wtfplayer commands.
2. Some sort of USB serial connection between the two, also only passing wtfplayer commands.
I am looking for an approach which A) Does not disrupt the low-jitter environment of your system, and B) requires the least amount of packages to be added to your currently very lean linux distro.
Also, I noticed your name sounds very very Polish, and it appears the forum is showing a Polish flag next to your account. I happen to be American living in Poland with my (polish) girlfriend ATM.
Mieszka w Wrocławiu teraz.
What a coincidence if you happen to be from Poland! Lubię twój Kraj!
Frederyk, Cześć!
I am soon to try your system on an old computer for playing on a frugalhorn mark 3.
I had the thought today of possibly trying to write a mycroft skill to control wtfplay remotely. It seemed to me that this would preserve the elegance of your system, and what I assume to be it's lack of jitter because the entire computer is only dedicated to playing audio, while gaining an intuitive (voice-controlled) interface running remotely on a seperate device (a mycroft).
However, of-course, the mycroft on a separate device would somehow have to communicate with wtfplay. Do you recommend one of the following approaches (or another I haven't thought of)? My thoughts were:
1. Direct Ethernet cable from mycroft to wtfplay machine, only passing wtfplayer commands.
2. Some sort of USB serial connection between the two, also only passing wtfplayer commands.
I am looking for an approach which A) Does not disrupt the low-jitter environment of your system, and B) requires the least amount of packages to be added to your currently very lean linux distro.
Also, I noticed your name sounds very very Polish, and it appears the forum is showing a Polish flag next to your account. I happen to be American living in Poland with my (polish) girlfriend ATM.
Mieszka w Wrocławiu teraz.
What a coincidence if you happen to be from Poland! Lubię twój Kraj!
Cześć frd!
I am soon to build a wtfplay system to run with my new frugalhorn MK3's.
I had the thought today to try and build a mycroft skill to control wtfplay remotely from a seperate device by voice (a mycroft). My thought was that such a project would allow a very nice voice-controlled UI, while preserving the elegant and low-jitter system you've built. Ofcourse, to do so, somehow the mycroft would have to communicate with the machine running wtfplay. I am curious to know if you have any recommendations. Here are my current thoughts:
1. Run an ethernet cable between my mycroft and wtf-play, and only send wtfplayer commands over that cable (So, I would have to install some sort of minimum network capability on wtfplayer)
2. Run a USB cable between the two, and send wtfplayer commands over that serial line.
I am ofcourse asking with 2 things in mind: 1) Which method preserves the low-jitter environment the best, which is producing such great audio from your system? and 2) Which method introduces the least amount of new packages to be installed on your already very lean and elegant linux distro?
Btw, I noticed on wtfplay website your name sounds very Polish, and it appears you have a polish flag showing on this forum. I happen to be an American living in Poland right now, with my (Polish) girlfriend. What a coincidence! Lubię twój Kraj! Mieszkam w Wrocławia teraz!
I am soon to build a wtfplay system to run with my new frugalhorn MK3's.
I had the thought today to try and build a mycroft skill to control wtfplay remotely from a seperate device by voice (a mycroft). My thought was that such a project would allow a very nice voice-controlled UI, while preserving the elegant and low-jitter system you've built. Ofcourse, to do so, somehow the mycroft would have to communicate with the machine running wtfplay. I am curious to know if you have any recommendations. Here are my current thoughts:
1. Run an ethernet cable between my mycroft and wtf-play, and only send wtfplayer commands over that cable (So, I would have to install some sort of minimum network capability on wtfplayer)
2. Run a USB cable between the two, and send wtfplayer commands over that serial line.
I am ofcourse asking with 2 things in mind: 1) Which method preserves the low-jitter environment the best, which is producing such great audio from your system? and 2) Which method introduces the least amount of new packages to be installed on your already very lean and elegant linux distro?
Btw, I noticed on wtfplay website your name sounds very Polish, and it appears you have a polish flag showing on this forum. I happen to be an American living in Poland right now, with my (Polish) girlfriend. What a coincidence! Lubię twój Kraj! Mieszkam w Wrocławia teraz!
Hi Colinbrogan,
The general philosophy in wtfplay-live is to avoid anything that is not strictly necessary for audio playback. That is why there is no network support. I am afraid that the support for USB-UART converters is not there either.
The only driver that is built-in is for 8250 UART controller. If you computer has a RS232 port then it should be supported. Having said that, I have not tried that myself, and I think it will not work out of the box. There is probably some configuration missing to get the console running.
As for the other two options that you mention:
1. The network support would require a kernel with the network stack and Ethernet card (and WiFi?) drivers + some associated user-space programs.
2. The serial console with USB-UART converters would require adding kernel drivers for those devices. The rest should be similar to any other serial port configuration, but I guess, some experimenting/tweaking will be required.
I hope that this helps.
F
The general philosophy in wtfplay-live is to avoid anything that is not strictly necessary for audio playback. That is why there is no network support. I am afraid that the support for USB-UART converters is not there either.
The only driver that is built-in is for 8250 UART controller. If you computer has a RS232 port then it should be supported. Having said that, I have not tried that myself, and I think it will not work out of the box. There is probably some configuration missing to get the console running.
As for the other two options that you mention:
1. The network support would require a kernel with the network stack and Ethernet card (and WiFi?) drivers + some associated user-space programs.
2. The serial console with USB-UART converters would require adding kernel drivers for those devices. The rest should be similar to any other serial port configuration, but I guess, some experimenting/tweaking will be required.
I hope that this helps.
F
Ah, yes, RS232! I didn't think about that. I do have it on the PC I will use for wtfplay-live. I am not sure how common it is on modern computers if I make my steps reproducible, but it seems to be the easiest way to start.
If I do this project, would you like me to post the progress on your thread? Let me know if you feel that would be hi-jacking the thread with distractions, but if this project is of use to the broader community using wtf-play, I am happy to share the results. Hopefully I can get it down to a single bash script to run on your distro, to configure the port and download a minimal script which operates your player via the port. A kind of RS232 API for your command line players is the idea. Then on the mycroft side, assuming that Raspbian supports USB => RS232 adapters out of the box (which appears to be so), and python can communicate with that port out of the box (which also appears to be so), then it would just be a matter of downloading the mycroft skill on a standard mycroft mark i, and plugging in the adapter and cable. We will see!
Amazing work on this distro! I am quite excited to be able to use it for this project!
If I do this project, would you like me to post the progress on your thread? Let me know if you feel that would be hi-jacking the thread with distractions, but if this project is of use to the broader community using wtf-play, I am happy to share the results. Hopefully I can get it down to a single bash script to run on your distro, to configure the port and download a minimal script which operates your player via the port. A kind of RS232 API for your command line players is the idea. Then on the mycroft side, assuming that Raspbian supports USB => RS232 adapters out of the box (which appears to be so), and python can communicate with that port out of the box (which also appears to be so), then it would just be a matter of downloading the mycroft skill on a standard mycroft mark i, and plugging in the adapter and cable. We will see!
Amazing work on this distro! I am quite excited to be able to use it for this project!
To enable serial console in the current release a manual action is required.
When booting in BIOS mode:
When booting in UEFI mode:
In boot cases, kernel will print the messages to the serial port and you will be able to see them once you attach plug the serial cable to another computer and run a serial terminal program (e.g. Putty under Windows, picocom under Linux). This is where you will see the command prompt.
The configuration for the terminal program is as follows:
Note, that currently, when the serial port console is used your keyboard will remain inactive.
I hope that you will find it helpful.
F
When booting in BIOS mode:
- Interrupt the bootloader with Tab key
- Append the following kernel parameter: console=ttyS0,115200n8
- Hit Enter key to boot the kernel
When booting in UEFI mode:
- Interrupt the bootloader by pressing any key
- Enable editing for the highlighted menu entry by pressing e key
- Navigate to the line that starts with "linux ..."
- Append the following kernel parameter: console=ttyS0,115200n8
- Press F10 to boot the kernel
In boot cases, kernel will print the messages to the serial port and you will be able to see them once you attach plug the serial cable to another computer and run a serial terminal program (e.g. Putty under Windows, picocom under Linux). This is where you will see the command prompt.
The configuration for the terminal program is as follows:
- Baudrate: 115200
- Data bits: 8
- Stop bits: 1
- Parity: none
- Flow control: none
Note, that currently, when the serial port console is used your keyboard will remain inactive.
I hope that you will find it helpful.
F
I did not realize that a remote console over a serial port was possible by default in linux. I was assuming that I would have to write some special program to read and write from a serial line, and fire your wtfplayer accordingly. This is great! Makes my task much easier.
I am waiting on an RS232 cable to come via allegro.pl to test all of this. In the meantime, I did some reading and also noticed this article on kernal.org: Linux Serial Console — The Linux Kernel documentation
In addition to RS232, it mentions a serial console via "ttyUSB0". Do you think this kernel parameter would work on your wtfplay-live distribution? If not, RS232 is good enough. However, my thought is that if it is possible, USB would be superior on 2 fronts:
1. In 2021, USB ports are pretty much universal on motherboards, and the cables are more common. RS232 is far less common.
2. According to wikipedia, the RS232 spec has "Single-ended signaling referred to a common signal ground", which "limits the noise immunity." If I read that sentence right, I am guessing that more electronic noise could get into the system with this connection, then presumably USB. Though, this is pure speculation, as I am no expert in electronics. I am assuming that wtfplay sounds very good because the minimal system acheives lower jitter.
Also, I absolutely love the fact that your system is only 24MB! Well done!
I am waiting on an RS232 cable to come via allegro.pl to test all of this. In the meantime, I did some reading and also noticed this article on kernal.org: Linux Serial Console — The Linux Kernel documentation
In addition to RS232, it mentions a serial console via "ttyUSB0". Do you think this kernel parameter would work on your wtfplay-live distribution? If not, RS232 is good enough. However, my thought is that if it is possible, USB would be superior on 2 fronts:
1. In 2021, USB ports are pretty much universal on motherboards, and the cables are more common. RS232 is far less common.
2. According to wikipedia, the RS232 spec has "Single-ended signaling referred to a common signal ground", which "limits the noise immunity." If I read that sentence right, I am guessing that more electronic noise could get into the system with this connection, then presumably USB. Though, this is pure speculation, as I am no expert in electronics. I am assuming that wtfplay sounds very good because the minimal system acheives lower jitter.
Also, I absolutely love the fact that your system is only 24MB! Well done!
I did some experimentation tonight on wtfplay-live, and am starting to answer my own questions.
It appears that connecting a USB cable directly between two computers will never work, insofar as both computer's USB ports are *host* controllers. It appears to me that the ttyUSB0 kernel parameter is actually designed to output to some sort of USB to serial conversion cable, and not USB to USB, as I naively assumed.
I guess I will just have to wait on this RS252 cable then.
What bootloader are you using? I looked for a grub configuration file, to permanently change the kernel parameters, and didn't find it. You must be using something else then?
It appears that connecting a USB cable directly between two computers will never work, insofar as both computer's USB ports are *host* controllers. It appears to me that the ttyUSB0 kernel parameter is actually designed to output to some sort of USB to serial conversion cable, and not USB to USB, as I naively assumed.
I guess I will just have to wait on this RS252 cable then.
What bootloader are you using? I looked for a grub configuration file, to permanently change the kernel parameters, and didn't find it. You must be using something else then?
Aha. I found "isolinux.cfg" on my thumb drive. So if I want serial console to work on every boot permanently, without having to edit grub at runtime, I can just add the kernel parameters like so, right?:
Can't wait to get my RS232 cable. It appears so far that, having this permanent kernel parameter will solve everything I need from wtfplay. I can then entirely focus on writing the mycroft skill in python, which will do all the work.
Can't wait to get my RS232 cable. It appears so far that, having this permanent kernel parameter will solve everything I need from wtfplay. I can then entirely focus on writing the mycroft skill in python, which will do all the work.
That looks correct. Just try entering parameter manually first play with that first.
I do not think that you will be able to edit that file though. The ISO image that is being written onto the memory stick uses ISO9660 file system, which is read only.
That makes me thinking. Maybe I should not bother with ISO images anymore? It's hard to imagine that people these days boot wtfplay-live from the optical disk.
I do not think that you will be able to edit that file though. The ISO image that is being written onto the memory stick uses ISO9660 file system, which is read only.
That makes me thinking. Maybe I should not bother with ISO images anymore? It's hard to imagine that people these days boot wtfplay-live from the optical disk.
Yes, I did try it manually, but I don't have the cable yet, so I can't yet see if it will work until Monday.
I think the last time I burned a CD or DVD was maybe 2009. But I can't speak for everyone.
I see what you are saying now. It appears I would have to extract the ISO, modify that configuration file, and then generate a new ISO. Not too bad. But I guess if many more people wanted to do what I am doing, then having it in a format which can be edited directly on the thumb drive would be more convenient. Also, as USB drives are quite large these days, some people might want to load their music directly on the same thumb drive to start. Having a third partition which is writable might be nice for that. Although, this isn't a feature I care all that much about.
I do love that you seperated the config partition to store state information (plist and the like). It makes the live distro work quite nicely, where you don't have to install it on any computer's hard disk permanently, and yet you get to keep your playlists. Nice design.
I think the last time I burned a CD or DVD was maybe 2009. But I can't speak for everyone.
I see what you are saying now. It appears I would have to extract the ISO, modify that configuration file, and then generate a new ISO. Not too bad. But I guess if many more people wanted to do what I am doing, then having it in a format which can be edited directly on the thumb drive would be more convenient. Also, as USB drives are quite large these days, some people might want to load their music directly on the same thumb drive to start. Having a third partition which is writable might be nice for that. Although, this isn't a feature I care all that much about.
I do love that you seperated the config partition to store state information (plist and the like). It makes the live distro work quite nicely, where you don't have to install it on any computer's hard disk permanently, and yet you get to keep your playlists. Nice design.
Something I have noticed for quite awhile, over a year and before that I am not sure, and wonder if it has more to do with my computer than with WTFPLAY: when a track begins the left channel is delayed by almost a second - like theater lighting it comes in gradually over that second.
Another one of those things i gladly live with but thought I would ask if anyone else has this anomaly.
Any idea what could be causing this if it is software related>
As always, thanks to frd for his great contribution to the enjoyment of listening to music at home.
Another one of those things i gladly live with but thought I would ask if anyone else has this anomaly.
Any idea what could be causing this if it is software related>
As always, thanks to frd for his great contribution to the enjoyment of listening to music at home.
Dear frd,
Another one of my goofy questions.
The other night I did not realize I had not moved a DSD album into my DSD folder so when I wanted to hear the BEACH BOYS/SURF'S UP I was surprised to see my DAC say DSD.
I was even more surprised to hear music playing since I have my player set to PCM and thought that it would not recognize the format.
I know in the previous version of the player DSD files would not play in PCM.
Since going from PCM player to DSD player is a bit of a pain I am eventually going to use two separate SD cards for each WHICH leads to my real question:
Would there be any advantage to having a version of the player that was specific to each of these formats? I know you are also a believer in minimizing the size of the player but have no idea if this would result in any significant reduction total size.
Wondering if this could make a difference would you show how to do it or would it require someone with your expertise to do this?
I know with WINDOWS it was easy to play around!
Let me know, please.
Thanks and take care,
Another one of my goofy questions.
The other night I did not realize I had not moved a DSD album into my DSD folder so when I wanted to hear the BEACH BOYS/SURF'S UP I was surprised to see my DAC say DSD.
I was even more surprised to hear music playing since I have my player set to PCM and thought that it would not recognize the format.
I know in the previous version of the player DSD files would not play in PCM.
Since going from PCM player to DSD player is a bit of a pain I am eventually going to use two separate SD cards for each WHICH leads to my real question:
Would there be any advantage to having a version of the player that was specific to each of these formats? I know you are also a believer in minimizing the size of the player but have no idea if this would result in any significant reduction total size.
Wondering if this could make a difference would you show how to do it or would it require someone with your expertise to do this?
I know with WINDOWS it was easy to play around!
Let me know, please.
Thanks and take care,
Hi Rick,
Here is a summary of which version of the player supports what:
I hope that this will help.
F
Here is a summary of which version of the player supports what:
Code:
Player Supported DSD Supported PCM
----------- ----------------- ------------------
wtfplay DSF (DoP) WAV, FLAC
wtfplay-dsd DSF (Native, DoP) WAV, FLAC
wtfplay-pcm - WAV, FLAC
wtfplay-wav - WAVI hope that this will help.
F
Well, that is what I would have thought.
So would you say I have a corrupted OS if wav will play a DSD file? I just realized I meant to type pcm not wav.
I will reload it tonight and see if that is the case.
The second part was wondering if there could be a version that would be for , I mean PCM, and one that would be for DSD and if it would result in any reduction in the size of the OS?
So would you say I have a corrupted OS if wav will play a DSD file? I just realized I meant to type pcm not wav.
I will reload it tonight and see if that is the case.
The second part was wondering if there could be a version that would be for , I mean PCM, and one that would be for DSD and if it would result in any reduction in the size of the OS?
Last edited:
If -wav/-wav version plays a DSD file, then I can see two options:
1. I messed something up while releasing the software
2. The DSD file is a DoP WAV or FLAC floac. This is where DSD material is split into 16bit chunks, each chunk it wrapped in the DoP container and all that lives in a WAV/FLAC file. The player threats that as regular PCM data. The DAC (or USB/I2S converter) then is able to detect the DoP altering pattern and to extract DSD bitstream from it.
The -pcm and -wav versions were created purely for experimentation. I guess, the -dsdonly could be created for the same purpose. As for question, whether this would be beneficial - this is something you would need to determine yourself.
F
1. I messed something up while releasing the software
2. The DSD file is a DoP WAV or FLAC floac. This is where DSD material is split into 16bit chunks, each chunk it wrapped in the DoP container and all that lives in a WAV/FLAC file. The player threats that as regular PCM data. The DAC (or USB/I2S converter) then is able to detect the DoP altering pattern and to extract DSD bitstream from it.
The -pcm and -wav versions were created purely for experimentation. I guess, the -dsdonly could be created for the same purpose. As for question, whether this would be beneficial - this is something you would need to determine yourself.
F